Yes dont use non cache for temporary queues as they are temporary and only associated with the session.
On Fri, Jul 26, 2013 at 9:09 PM, Mike Pilone <[email protected]> wrote: > I believe I found a bug in the JMS request/reply implementation if the > replyToCacheLevelName is set to CACHE_NONE in the JmsConfiguration. The > issue is that with CACHE_NONE, the DefaultMessageListenerContainer > superclass AbstractPollingMessageListenerContainer is responsible for > creating and closing a connection on each call to doReceiveAndExecute > (around line 287). > > Internal to the method, a new connection and session are created and the > createListenerConsumer is called to resolve the destination and create the > consumer. The bug is in the Camel TemporaryReplyQueueDestinationResolver > (in TemporaryQueueReplyManager (around line 201) where the temporary queue > is only refreshed if it is null or a refresh is requested (I.e. An > exception was previously raised). Because the connection is not cached, > each call to resolveDestinationName will have a new session and a new > connection but the same queue is returned. > > This causes an issue with ActiveMQ because temporary queues are per > connection, therefore they can't be shared across multiple connections as > the destination resolver is attempting to do. This results in the endless > exception: > > "" > [WARNING] Exception inside the DMLC for Temporary ReplyTo Queue for > destination episodes.retrieve.request, refreshing ReplyTo destination > javax.jms.InvalidDestinationException: Cannot use a Temporary destination > from another Connection > "" > > I don't think there is a quick fix here because of the way the reply > managers work, but the current implementation only works if: > 1) connection or greater caching is allowed in the DMLC > or > 2) use a SingleConnectionFactory from Spring to ensure that the same > connection is used for all requests from the DMLC so essentially you are > caching the connection in the factory. > > With a real connection pool implementation and DMLC CACHE_NONE, you'll get > random results depending on if the pool returns the same connection that > was used the first time the temporary reply destination was resolved. If a > different connection is returned, you'll get the exception. > > You can reproduce this with a request/reply endpoint, replyToCacheName set > to CACHE_NONE, and using ActiveMQConnectionFactory directly (that is, no > pooling or SingleConnectionFactory wrapper). > > Please let me know if this should be filed as a defect or if more > information is needed. > > -mike > > > |Mike Pilone | Software Architect, Distribution | [email protected] > > -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
