Hi,
the current implementation does not use a selector by default on the
reply queue. So each instance will receive all messages.
The old implementation created one consumer per request and used the
correlation id as selector. So it only received the messages it sent out.
The new implementation uses only one consumer per instance. So it cannot
set the selector to be the correlation id.
Currently you have two ways to cope with that. You can either use a
temporary reply queue or you can use different reply queues per instance.
It think using a temporary reply queue has no real disadvantages and it
is the easiest way.
If you think using a shared permanent reply queue for several instances
is important you could add a jira issue. I think we could implement this
by using a instance based prefix for the corraltion id and configuring
the selector to select for this string.
Greetings
Christian
Perch24 schrieb:
We recently upgraded to CXF 2.1.3 from 2.1.2. After the upgrade we noticed
that JMS conduits with a reply to queue were not always working if we had
multiple instances running. I didn't dive into the problem real deep, but
rather just removed the reply to queue config so that it would use a
temporary queue. That fixed the problem.
It looks like to me that the new implemenation of the JMS conduit is broken
if you have multiple instances of a conduit running against the same reply
to queue. It's possible that this could be fixed with the new Spring
configuration, but it is not backwards compatible with 2.1.2.
I'm posting this to list first to see if anyone else has seen this. Let me
know if you would like me to open a defect.
--
Christian Schneider
---
http://www.liquid-reality.de
