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 >> >> >> > > -- View this message in context: http://www.nabble.com/CXF-2.1.3-JMS-Conduit-tp20447067p21439720.html Sent from the cxf-user mailing list archive at Nabble.com.
