camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Bug in JMS Request/Reply with CACHE_NONE and Temporary Queues
Date Sun, 28 Jul 2013 06:32:52 GMT
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 <> 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 |

Claus Ibsen
Red Hat, Inc.
Twitter: davsclaus
Author of Camel in Action:

View raw message