camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: camel 2.5 JMS Request/Reply caching weirdness
Date Wed, 15 Dec 2010 14:36:44 GMT

I think once we used to use a SimpleMessageListenerContainer in the
reply logic in camel-jms.
Later we switched to DefaultMessageListenerContainer. There was a JIRA
ticket about that.

Maybe you can try changing the source to use the
SimpleMessageListenerContainer again?

On Tue, Dec 14, 2010 at 6:00 PM, Jason Burkhardt <> wrote:
> A little background:  I'm using FioranoMQ repeaters to share messages between
> different servers.  Request reply works over this by setting JMSReplyTo to a
> common destination being propagated between servers and setting
> JMSX_OriginalReplyTo to the actual destination the requester will be
> listening for a response on.  Their API handles all this leg work and it's
> transparent to normal JMS use.
> *I don't encounter this problem doing request/response all on the same
> server.*
> I've been using a Spring CachingConnectionFactory for both the client
> publishing requests and the client responding to the requests.  I've tried
> with Spring 3.0.0 and Spring 3.0.4.
> Using Camel 2.5:
> If I start up a responder client (nothing special about this client, it's
> just a <from> Camel JMS route), then start up a request client, the
> request/response behavior will work as expected.  However, if I stop the
> request client, but leave the responder client running, then start the
> request client again the request client will never receive any responses.
> This confused me so I experimented by setting an explicit replyTo on the
> requester route and the same test worked fine.  However, if I changed the
> replyTo to a different destination between taking the requestor client down
> and starting it back up again, the request client doesn't get the response.
> I watched what was happening on the JMS server and the responder was
> continuing to publish messages to the original replyTo topic.
> Looking more closely I watched the headers on the message in sendReply of
> EndpointMessageListener, contrary to what I was expecting the value of
> JMSX_OriginalReplyTo did have the correct value each time.  (I checked the
> headers of the camel JmsMessage and the Message that is created by the
> MessageCreator).
> At this point I was thoroughly confused.  For whatever reason I decided to
> experiment and set cacheProducers=false on the CachingConnectionFactory.
> This fixed things.  I can start/stop the requesting client as many times as
> I want and it will still receive responses, both for temporary destinations
> and explicit.
> It seems as if the producer is caching the JMSX_OriginalReplyTo header and
> reusing it for each send call.
> Using Camel 2.4:
> This all works fine.  I can use cacheProducers=true on the
> CachingConnectionFactory.   I can start/stop the requester client as many
> times as I want and it will continue to receive responses from the
> responder.  (Both temporary destinations and explicit destinations).
> I looked around in the JMS code to see what changed between 2.4 and 2.5 but
> I really don't see anything that would have changed the response publishing
> dynamic.  The EndpointMessageListener and CamelJmsTemplate seem to be
> largely the same.  Even if those changed I don't see how the underlying
> Spring CachingConnectionFactory would be exhibiting different behavior
> between Camel versions.
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Twitter: davsclaus
Author of Camel in Action:

View raw message