You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Marat Bedretdinov (JIRA)" <ji...@apache.org> on 2008/04/21 06:50:43 UTC
[jira] Created: (CAMEL-474) Provide a configurable strategy for
temporary replyTo destination scoping
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.
[jira] Closed: (CAMEL-474) Provide a configurable strategy for
temporary replyTo destination scoping
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marat Bedretdinov closed CAMEL-474.
-----------------------------------
Thanks Willem, Claus
> 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.
[jira] Commented: (CAMEL-474) Provide a configurable strategy for
temporary replyTo destination scoping
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (CAMEL-474) Provide a configurable strategy for
temporary replyTo destination scoping
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-474.
-------------------------------
Resolution: Fixed
Fixed by CAMEL-490
> 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.