Brian, Frank,
let's see if I am able to jump in here, assuming that I am one of
probably only a few people within Sun who has used JMSJCA in conjunction
with Spring in quite some depth in a "real-world" customer scenario ;-)
(Sorry, I also missed the original mail from December due to an extended
Christmas vacation...)
Frank Kieviet schrieb:
> I'm not very familiar with Spring, and the stack trace doesn't look
> like a known problem. Rather it looks like a problem in Spring. Do
> you still have this issue?
I wouldn't assume an issue with Spring in the first place.
Rather, I tend to think that the usage pattern and/or Spring feature(s)
as used by Brian might not be fully appropriate to the usage scenario:
Brian, please find my detailed set of questions/requests inline... :-)
> ------------------------------------------------------------------------
> *From:* Brian Repko [mailto:brianrepko_at_fastmail.us]
> *Subject:* Sessions are already closed
> I'm using the sun-jms-connector as a standard RAR (global) against
> which I send and receive cache flush notifications (listening on a
> topic).
> I continue to get JMSJCA-E153 messages (session is closed) when
> trying to send the notification. These cache flush notifications are
> generated by Hibernate (second level cache) and are part of a
> transaction synchronization.
> The event handler is OSCache which then delegates to my code to send
> the message. In my message sender, I have a Spring JmsTemplate that
> has the TopicConnectionFactory and the Topic.
If I got you right, this means that, at any point in time, an arbitrary
thread from the Java EE container (BTW: is your app using Hibernate from
the web container or the EJB container?) might call into your code
sending and receiving a cache flush notifications?
So please forward some more details about the setup of your app:
- the definition of your JMSJCA connection pools/resources in Glassfish
- your Spring application context
and some details on how you are using the JMSJCA TCF and/or other Spring
features from within your application code.
As a starting point, here is a snippet of one of my application contexts
that is proven to successfully send transactional messages using JMSJCA
5.1.3 from the Sun App Server 8.1 web container:
<bean id="jmsTopicConnectionFactory"
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="resourceRef">
<value>true</value>
</property>
<property name="jndiName">
<value>jms/XAOutTopicCF</value>
</property>
</bean>
<bean id="jmsTopicTemplate"
class="org.springframework.jms.core.JmsTemplate">
<property name="connectionFactory"
ref="jmsTopicConnectionFactory" />
<property name="pubSubDomain" value="true" />
</bean>
<bean id="jmsDestination"
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="resourceRef">
<value>true</value>
</property>
<property name="jndiName">
<value>jms/OutboundTopic</value>
</property>
</bean>
<bean id="messageSender"
class="com.sun.germany.vine2.wsn.consumer.jms.JmsMessageSenderImpl">
<constructor-arg ref="jmsTemplate" />
<constructor-arg ref="jmsDestination" />
</bean>
The respective pool/resource definitions are as follows:
$ASADMIN create-connector-connection-pool --echo --user admin \
--host $HOST --port $PORT --secure \
--passwordfile $PASSWORD_FILE --steadypoolsize 4 \
--maxpoolsize 32 --poolresize 2 --maxwait 60000 \
--idletimeout 3300 --failconnection=false --raname raunifiedjms \
--transactionsupport XATransaction \
--connectiondefinition javax.jms.TopicConnectionFactory \
--description "JMSJCA XA Outbound Topic Connection Pool" \
--property ConnectionURL=${JMS_URL}:\
UserName=admin:Password=admin:\
ProducerPooling=true:IdleTimeout=86400000 \
jms/XAOutTopicPool
$ASADMIN create-connector-resource --echo --user admin \
--host $HOST --port $PORT --secure \
--passwordfile $PASSWORD_FILE \
--target $TARGET \
--description "JMSJCA XA Outbound Topic Connection Factory" \
--poolname jms/XAOutTopicPool jms/XAOutTopicCF
$ASADMIN create-admin-object --echo --user admin \
--host $HOST --port $PORT --secure \
--passwordfile $PASSWORD_FILE \
--raname raunifiedjms --restype javax.jms.Topic \
--description "Outbound JMS Topic" \
--property Name=yourDesiredTopicName \
--target $TARGET jms/OutboundTopic
> I'm wondering if there is an option that folks know about for keeping
> the session open (or forcing a new session). I'm not sure about
> ProducerPooling and will try that.
Yes, you should definitely use JMSJCA ProducerPooling in your JMSJCA
connection pool setup in order to make JMSJCA do exactly what the option
says: pool JMS MessageProducers (QueueSeners, TopicPublishers).
To pool JMS Connections and JMS Sessions is the job of the JMSJCA
resource adapter and the JMS resources referring to it as defined in
Glassfish.
Also, please be warned that in order to do any inbound message
processing from the web container, you should definitely use the JCA
support that comes with Spring >= 2.5 (JmsMessageEndpointManager) and
not try to fiddle with the MessageListenerContainer approach (as the
latter effectively only works in "JMSJCA.BypassRA=true" mode).
Based on your application context and Glassfish resource definitions, I
hope to be able to provide more specific advice...
Hope this helps & best regards,
Andreas
--
Andreas Loew
Senior Java Architect
Sun Microsystems (Germany)