cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rgavlin <>
Subject Re: CXF 2.1.3 JMS Conduit
Date Thu, 13 Nov 2008 07:20:20 GMT


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.


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
> ---

View this message in context:
Sent from the cxf-user mailing list archive at

View raw message