[ 
https://issues.apache.org/jira/browse/CXF-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663563#action_12663563
 ] 

Christian Schneider commented on CXF-1978:
------------------------------------------

Currently the implementation of JMSConduit starts one listener per Conduit. So 
it is not possible to have a filter on the exact correlation id.
Could we perhaps create the correlation id in a way that allows us to set up a 
filter that matches all messages for a certain conduit?

The current correlation id works like correlationId = host + "_" + userName + 
"_" + threadId + timeInMillies

Theoretically it should work if we use a correlationId like host + "_" + 
userName + "_" + threadId + "%"

We use a spring DefaultMessageListenerContainer for the listener. This allows a 
messageSelector to be set. Do you think it should work when setting the 
selector to the above?

In any case we should also support a mode where the conduit accepts all 
messages and does not do correlation to get a real asynchronous behaviour. This 
is of course only possible if the client is also asnychronous and uses a 
handler for the reply.

> Spring-based JMS Conduit should support using a shared permanent reply queue 
> for several instances
> --------------------------------------------------------------------------------------------------
>
>                 Key: CXF-1978
>                 URL: https://issues.apache.org/jira/browse/CXF-1978
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.9, 2.1.3
>            Reporter: Ron Gavlin
>
> The new Spring-based JMS Conduit should support using a shared permanent 
> reply queue for several instances. 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. This may be 
> considered a "regression" introduced during the upgrade from CXF 2.1.2 to 
> 2.1.3.
> See Nabble Thread 
> http://www.nabble.com/forum/ViewPost.jtp?post=20447067&framed=y.
> /Ron

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to