It wouldn't matter either way. From the stack trace Spring's
DefaultMessageListenerContainer is being used for the consumer and they
don't recommend using pooled connections for that class. They document
this in their javadocs:
* <p><b>Note: Don't use Spring's {@link
org.springframework.jms.connection.CachingConnectionFactory}
* in combination with dynamic scaling.</b> Ideally, don't use it with a
message
* listener container at all, since it is *generally preferable to let the*
* * listener container itself handle appropriate caching within its
lifecycle.*
* * Also, stopping and restarting a listener container will only work with
an*
* * independent, locally cached Connection - not with an externally cached
one.*
The last line is what leads me to believe the the use of a cached
connection is the reason that the listener container didn't recover from
the exception and automatically reconnect as it should.
-Chris
On Sat, Jun 27, 2015 at 10:42 AM, Tim Bain <tb...@alumni.duke.edu> wrote:
> Chris,
>
> Would that advice (to not use pooling if you client was solely a consumer)
> apply even if the OP was not running inside a container? I didn't see
> anything in the description that indicated whether this setup included a
> container...
>
> Tim
> On Jun 26, 2015 10:34 AM, "Christopher Shannon" <
> christopher.l.shan...@gmail.com> wrote:
>
> > Hi,
> >
> > It's generally not recommended to use a pool of connections when using a
> > listener container. Pooled connections are mostly useful for Message
> > producers. In fact if you look at the documentation for the
> > DefaultMessageListenerContainer (which is the parent of
> > DefaultJmsMessageListenerContainer) it recommends not to use a caching
> > connection factory (their version of pooling connections) and to let the
> > container manage it. Since message listeners are long running there
> isn't
> > much benefit to using a connection out of a connection pool.
> >
> > So, I would try running your DefaultJmsMessageListenerContainer without a
> > pooled connection and see if that works. The
> > DefaultMessageListenerContainer implementation should automatically
> > reconnect on exception if it is managing its own connection.
> >
> > -Chris
> >
> >
> >
> > On Fri, Jun 26, 2015 at 2:23 AM, A.Marchand <a.march...@progeri.com>
> > wrote:
> >
> > > Hi,
> > >
> > > We are heavy camel and activemq users. We experience a small problem
> that
> > > is
> > > easily reproducible.
> > >
> > > We use Camel to connect to activemq. We link with the version 5.11.1 of
> > the
> > > activemq libraries.
> > > We use Camel version 2.14 but it is probably not relevant in this
> > context.
> > >
> > > We create a pool of connection in the camel via spring.
> > >
> > > <bean id="jms"
> > > class="org.apache.activemq.camel.component.ActiveMQComponent">
> > > <property name="brokerURL" value="tcp://127.0.0.1:61616"/>
> > > </bean>
> > >
> > > And after that a route listening to a topic and pushing the result into
> > > another one such as:
> > >
> > > <route>
> > > <from uri="jms:topic:aaaa"/>
> > > <to uri="jms:topic:bbbb"/>
> > > </route>
> > >
> > > Everything is working perfectly.
> > >
> > > BUT, now we use a socket killer software in order to kill one of the
> > > connection to the broker (Client side). On windows this can be done via
> > > TCPVIEW.exe.
> > >
> > > The system detects the deconnection and gives the following log:
> > >
> > > 16:25:45,618 INFO PooledConnectionFactory:110 - Expiring connection
> > > ActiveMQConnection
> > >
> > >
> >
> {id=ID:XXXXXXXX-2550-1435241073096-1:1,clientId=ID:XXXXXXXXX-2550-1435241073096-0:1,started=false}
> > > on IOException: java.net.SocketException: Connection reset
> > >
> > > Which is perfect, but after that, the system will never recover and
> will
> > > keep on logging the following error:
> > >
> > > 16:33:31,389 WARN DefaultJmsMessageListenerContainer:839 - Setup of
> JMS
> > > message listener invoker failed for destination 'XXXXXXXXXX' - trying
> to
> > > recover. Cause: The Session is closed
> > > javax.jms.IllegalStateException: The Session is closed
> > > at
> > >
> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:767)
> > > at
> > >
> >
> org.apache.activemq.ActiveMQSession.createTopic(ActiveMQSession.java:1294)
> > > at
> > >
> > >
> >
> org.apache.activemq.jms.pool.PooledSession.createTopic(PooledSession.java:247)
> > > at
> > >
> > >
> >
> org.springframework.jms.support.destination.DynamicDestinationResolver.resolveTopic(DynamicDestinationResolver.java:82)
> > > at
> > >
> > >
> >
> org.springframework.jms.support.destination.DynamicDestinationResolver.resolveDestinationName(DynamicDestinationResolver.java:63)
> > > at
> > >
> > >
> >
> org.springframework.jms.support.destination.JmsDestinationAccessor.resolveDestinationName(JmsDestinationAccessor.java:100)
> > > at
> > >
> > >
> >
> org.springframework.jms.listener.AbstractPollingMessageListenerContainer.createListenerConsumer(AbstractPollingMessageListenerContainer.java:221)
> > > at
> > >
> > >
> >
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.initResourcesIfNecessary(DefaultMessageListenerContainer.java:1124)
> > > at
> > >
> > >
> >
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1100)
> > > at
> > >
> > >
> >
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1093)
> > > at
> > >
> > >
> >
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:990)
> > > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> > > Source)
> > > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> > > Source)
> > > at java.lang.Thread.run(Unknown Source)
> > > 16:33:31,389 INFO DefaultJmsMessageListenerContainer:891 -
> Successfully
> > > refreshed JMS Connection
> > > 16:33:36,396 WARN DefaultJmsMessageListenerContainer:839 - Setup of
> JMS
> > > message listener invoker failed for destination 'EVENT_SCREENS' -
> trying
> > to
> > > recover. Cause: The Session is closed
> > > javax.jms.IllegalStateException: The Session is closed
> > >
> > > The system will never recreate the session by itself and the client
> must
> > be
> > > restarted. The problem does not happen that often in the real life
> > > (Otherwise it would be unusable) but it arrives from time to time.
> > >
> > > Thanks for these amazing products.
> > >
> > > Regards,
> > >
> > > Arnaud
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://activemq.2283324.n4.nabble.com/ActiveMQ-Pooled-Session-tp4698203.html
> > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > >
> >
>
