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.
