thanks, i think that not having out of the box support 4 correllation of messages via their id is a serious issue. most users would expect this
On 1/13/09, Christian Schneider <[email protected]> wrote: > 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 > > -- Sent from Gmail for mobile | mobile.google.com
