Hi 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 <[email protected]> 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: > http://camel.465427.n5.nabble.com/camel-2-5-JMS-Request-Reply-caching-weirdness-tp3304901p3304901.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
