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 | mpil...@npr.org
