camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marat Bedretdinov (JIRA)" <>
Subject [jira] Closed: (CAMEL-490) Allow for persistent replyTo destinations
Date Mon, 12 May 2008 07:21:43 GMT


Marat Bedretdinov closed CAMEL-490.

Thanks Willem.

> Allow for persistent replyTo destinations
> -----------------------------------------
>                 Key: CAMEL-490
>                 URL:
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-jms
>    Affects Versions: 1.3.0
>            Reporter: Marat Bedretdinov
>            Assignee: Willem Jiang
>             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
> 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:

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

View raw message