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: https://issues.apache.org/jira/browse/AMQNET-371 On Wed, Mar 7, 2012 at 5:31 AM, Timothy Bish <tabish...@gmail.com> 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 > tim.b...@fusesource.com | www.fusesource.com > skype: tabish121 | twitter: @tabish121 > blog: http://timbish.blogspot.com/ > >
