camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Pilone <>
Subject Re: Bug in JMS Request/Reply with CACHE_NONE and Temporary Queues
Date Mon, 29 Jul 2013 02:05:56 GMT
Thanks for the confirmation. It should probably clearly noted in the request/reply documentation
as it is a pretty easy way to get yourself into a completely unusable configuration.


[cid:E1349351-5850-49F3-9008-CF9129E02D3C] | Mike Pilone | Software Architect, Distribution
|<> | o: 202-513-2679  m: 703-969-7493

From: Claus Ibsen <<>>
Reply-To: "<>" <<>>
Date: Sunday, July 28, 2013 2:53 AM
To: "<>" <<>>
Subject: Re: Bug in JMS Request/Reply with CACHE_NONE and Temporary Queues


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 <<>>
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 <<>>
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

[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
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 Pilone | Software Architect, Distribution |<>

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

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

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message