camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Burkhardt <jburkha...@gmail.com>
Subject Re: camel 2.5 JMS Request/Reply caching weirdness
Date Wed, 15 Dec 2010 17:11:34 GMT
I did notice in the reply manager it used a DefaultMessageListenerContainer
now, even for temporary destinations,  I tried swapping it back to a
SimpleMessageListenerContainer before figuring out the receive reply side
was working ok.
It's only on the send response side where I'm seeing the strangeness.

The EndpointMessageListener gets the message, initiates the processInOut
code and calls sendReply.  In sendReply I can verify to see that the
JMSX_OriginalReplyTo header is set to the proper value (both on the camel
message and the created jms message).   Despite that the message sent out
still has JMSX_OriginalReplyTo set to the old (presumably cached) value.  I
can use tcpdump to watch the outgoing traffic to see the header is indeed
set to the old value.
It seems sendReply just uses the CamelJmsTemplate defined in
JmsConfiguration to publish responses and I didn't see any big differences
in that code other than the old 1.0.2 support was removed.


On Wed, Dec 15, 2010 at 9:36 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> 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 <jburkhardt@gmail.com>
> 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: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>

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