Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <1728386028.1231969979580.JavaMail.jira@brutus>
Date: Wed, 14 Jan 2009 13:52:59 -0800 (PST)
From: "Christian Schneider (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Commented: (CXF-1978) Spring-based JMS Conduit should
 support using a shared permanent reply queue for several instances
In-Reply-To: <319878521.1231866963663.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Hi Ron,

the code you mentioned uses the doReceive function of the JmsTemplate. The disadvantage of this aproach is that it creates a new consumer for each request. I would like to keep the style of having one consumer per conduit. I hope the selector with "like" and a suitable correlationId that has a common prefix for all messages of the conduit can do this trick.

If this does not work we could of course use doReceive for the case of permanent queues. But I think this could have a negative impact on performance.

Greetings

Christian


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