[
https://issues.apache.org/activemq/browse/CAMEL-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42517#action_42517
]
Marat Bedretdinov commented on CAMEL-474:
-----------------------------------------
There is a patch attached to http://issues.apache.org/activemq/browse/CAMEL-490
that addresses this issue.
One can now configure the affinity between producer and temporary destination
used for receiving replies. Note that this variable only applies to temporary
replyTo destinations. For persistent replyTo destination this property is
ignored.
This configuration property "replyToTempDestinationAffinity" can can have
these values: "component", "endpoint", "producer". The default value is
"endpoint"
component - a single temp queue is shared among all producers for a given
component instance
endpoint - a single temp queue is shared among all producers for a given
endpoint instance
producer - a single temp queue is created per producer
> Provide a configurable strategy for temporary replyTo destination scoping
> -------------------------------------------------------------------------
>
> Key: CAMEL-474
> URL: https://issues.apache.org/activemq/browse/CAMEL-474
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-jms
> Affects Versions: 1.3.0
> Reporter: Marat Bedretdinov
> Fix For: 1.4.0
>
>
> Currently in request/reply scenarios a temporary replyTo destination is
> created and is shared among all Producers that were created from a given
> named JMS Component instance. If those Producers are then uses to correlate
> message flows among endpoints that are part of the same call flow using
> component generated or user provided correlation ID (not message ID), then
> there is a guaranteed reply loss:
> client -> jsm1.producer1 -> corrId -> jsm1.consumer1 -> jsm1.producer2 ->
> corrId -> jsmX.consumer
> jsm1.producer1 (@) <- corrId <- jsm1. consumer1 <-
> jsm1.producer2 <- corrId <- reply
> @ - point of reply message being dropped due to the fact that jsm1.producer2
> has already consumed a reply message with the same corrId and has disposed of
> outstanding request entry mapped to the same corrID
> Note that while this configuration breaks under outlined conditions it's an
> optimum way of correlating call flow when messageID is used as correlationID.
> Hence a way to fix this would be to keep the current strategy while allowing
> to configure the component to create a temporary replyTo destination per
> Producer instance, insulating producers from competing for reply messages
> correlated on the same id
> I'll probably take care of this one shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
