cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-1978) Spring-based JMS Conduit should support using a shared permanent reply queue for several instances
Date Wed, 14 Jan 2009 00:12:59 GMT

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


Mime
View raw message