activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gomes <>
Subject Re: NMSReplyTo and JMSReplyTo
Date Thu, 08 Mar 2012 01:28:31 GMT
A bit of a heads-up, when using a a Request/Reply pattern, *don't* use temp
queues.  Temp queues (and temp topics) are severely broken in the ActiveMQ
5.4.x and 5.5.x versions.  They will only work for a short time before the
broker uses up whatever resources, and then it will kick your client off
and even the failover protocol won't save you.  The best solution, even in
the absence of this bug, is to use a designated topic for the reply message
and to use the NMSCorrelationId to filter out replies destined for a
particular client.  It's faster, and it provides complete message
round-trip transparency.

Refer here to track the status of this problem:

On Wed, Mar 7, 2012 at 5:31 AM, Timothy Bish <> wrote:

> On Wed, 2012-03-07 at 14:26 +0100, Knut Aksnes-NOR wrote:
> > Will a JMSReplyTo property created by a Java sender be made available
> and be usable as a NMSReplyTo attribute by a .NET client using NMS with the
> ActiveMQ provider?
> >
> > We need to use the Request Reply EIP pattern from Camel against a
> component we intend to write in .NET (Mostly due to the availability of
> existing libraries)  For this to work more or less automatically we need
> JMSReplyTo to work, if it does so depends on serialization details for this
> attribute, this should be a quite easy question to answer for a protocol
> guru. I could dig into the code myself, but as the answer to the question
> should be made available as part of the NMS documentation and as a negative
> answer might trigger a change request I would prefer if some with good
> protocol knowledge could give an answer.
> Yes, the destination will be filled in correctly when using .NET and
> Java clients for ActiveMQ.
> --
> Tim Bish
> Sr Software Engineer | FuseSource Corp
> |
> skype: tabish121 | twitter: @tabish121
> blog:

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