Hi Adrian,
Ron Gavlin has opened an issue for this:
https://issues.apache.org/jira/browse/CXF-1978
I will write a comment about problems I see with the implementation in
the issue.
Greetings
Christian
Adrian C schrieb:
Hi,
Has a JIRA issue been opened for this - I haven't been able to find one.
This is quiet a serious issue and not the expected behavior. The expected
behavior is that multiple clients can consume off a shared queue - think of
any large scale deployment - this will not scale well if a client expecting
a response must setup its own specific queue. Any systems administrator
would blow their top at this. Imagine 100 clients to a web serivce that's
100 response queues!
This is a serious issue.
Thanks.
Adrian
rgavlin wrote:
Greetings,
The problem with temporary replyTo queues is that it is difficult to
semantically associate the temporary replyTo queues with their original
"request" queues. Using a named replyTo queue with a selector based on the
correlationId solves this problem. I'll be happy to open a jira if one has
not already been opened for this issue.
/Ron
Christian Schneider wrote:
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
--
Christian Schneider
---
http://www.liquid-reality.de
