Hi Logged a ticket to add validation to camel-jms to not allow CACHE_NONE for temp queues https://issues.apache.org/jira/browse/CAMEL-6580
On Sun, Jul 28, 2013 at 8:32 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > 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 <mpil...@npr.org> 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 | mpil...@npr.org >> >> > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: cib...@redhat.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen -- Claus Ibsen ----------------- Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
