[
https://issues.apache.org/jira/browse/CXF-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664082#action_12664082
]
Ron Gavlin commented on CXF-1978:
---------------------------------
Hi Christian,
In your proposal, what does the "%" in string [host + "_" + userName + "_" +
threadId + "%"] represent?
The latest revision of the smx JmsProviderEndpoint uses a listener container
when the replyDestination is supplied
(http://fisheye6.atlassian.com/browse/servicemix/components/bindings/servicemix-jms/trunk/src/main/java/org/apache/servicemix/jms/endpoints/JmsProviderEndpoint.java?r=734395)
and "doReceive" only when no replyDestination was configured or when an
alternate destination was choosen. How would you compare this strategy to the
one your are proposing?
/Ron
> 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.
