[jira] Updated: (CAMEL-490) Allow for persistent replyTo destinations

["Marat Bedretdinov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/activemq/browse/CAMEL-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marat Bedretdinov updated CAMEL-490:
------------------------------------

    Attachment: camel-jms-2008-05-02_21-08.patch

> Allow for persistent replyTo destinations
> -----------------------------------------
>
>                 Key: CAMEL-490
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-490
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-jms
>    Affects Versions: 1.3.0
>            Reporter: Marat Bedretdinov
>             Fix For: 1.4.0
>
>         Attachments: camel-jms-2008-05-02_21-08.patch
>
>
> Currently if there is a two way route using jms component replies are collected via a temporary destination. However it is also desirable to be able to have a persistent queue to be used as replyTo destination. 
> The attached patch address this requirement.
> in order to have a persistent replyTo destination used in your route the route should look like this:
> from("amq-1:queue:foo?replyTo=fooReply").to(...)
> There are two strategies for correlating requests and replies when the replyTo destination is a persistent one.
> 1. This is the same strategy that used when used with temporary replyTo destination. Either JMSCorrelationID or MessageID are used. No changes are needed to have JMSCorrelationID to correlate request with reply and useMessgeIDAsCorrelationID=true needs to be passed into the route URI or via configuration for using MessageID as correlation id. 
> For example: "amq-1:queue:foo?useMessgeIDAsCorrelationID=true&replyTo=queue:fooReply"
> However because this is a persistent replyTo destination and a shared resource the implementation has to dynamically update the consumer's selector waiting on possible replies in order to avoid consuming someone else's messages. This is very inefficient in JMS. 
> So to deal with this issues a second strategy is introduced.
> 2. The second strategy is to use a well known selector name that you provide at configuration time. This selector will then be used to create a reply awaiting consumer with a unique value for each of those consumer instances. To pass the selector name use this configuration property "replyToDestinationSelectorName".  
> For example: "amq-1:queue:foo?replyToDestinationSelectorName=replySelector&replyTo=queue:fooReply"
> This selector will be available in the Exchange's incoming message header in your ultimate destination processor or as a String property in JMSMessage. You will need to copy this property back into the reply message so that the reply consumer will have its selector match the reply's message selector value and receive the message
> This is a cumulative patch that address this Jira as well: https://issues.apache.org/activemq/browse/CAMEL-474

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