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:53:45 GMT

Logged a ticket to add validation to camel-jms to not allow CACHE_NONE
for temp queues

On Sun, Jul 28, 2013 at 8:32 AM, Claus Ibsen <> 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 <> 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.
> Email:
> Twitter: davsclaus
> Blog:
> Author of Camel in Action:

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

View raw message