You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Raul Kripalani (JIRA)" <ji...@apache.org> on 2012/07/24 19:01:36 UTC
[jira] [Created] (CAMEL-5465) JMS Reply Managers should remove
correlation earlier
Raul Kripalani created CAMEL-5465:
-------------------------------------
Summary: JMS Reply Managers should remove correlation earlier
Key: CAMEL-5465
URL: https://issues.apache.org/jira/browse/CAMEL-5465
Project: Camel
Issue Type: Bug
Components: camel-activemq, camel-jms
Affects Versions: 2.10.0, 2.9.2, 2.8.6
Reporter: Raul Kripalani
When handling synchronous invocations, both JMS reply managers {{TemporaryQueueReplyManager}} and {{PersistentQueueReplyManager}} remove the correlation too late.
{{ReplyManager.handleReplyMessage}} handles the reply triggering the continuation of the remaining route logic, which may as well contain yet another JMS invocation to exactly the same destination, e.g.:
{code}
<route>
<from uri="direct:hello" />
<inOut uri="activemq:queue:test" />
<inOut uri="activemq:queue:test" />
</route>
{code}
As a result, the correlation is not removed from the CorrelationMap until the asynchronous dispatch to the second endpoint has finished and the stack unwinds.
What's worse is that, due to Camel's re-use of endpoints, both producers are represented as exactly the same Endpoint instance, sharing *the same ReplyManager and CorrelationMap*.
So during the dispatch to the second endpoint, the correlation is overwritten in the CorrelationMap but, immediately after, the first endpoint removes the correlation anyway!
Since correlation ID are dragged on (see CAMEL-5390), the route will fail, providing a bad out-of-box experience for such a simple use case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5465) JMS Reply Managers should remove
correlation earlier
Posted by "Raul Kripalani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raul Kripalani resolved CAMEL-5465.
-----------------------------------
Resolution: Duplicate
> JMS Reply Managers should remove correlation earlier
> ----------------------------------------------------
>
> Key: CAMEL-5465
> URL: https://issues.apache.org/jira/browse/CAMEL-5465
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
> Affects Versions: 2.8.6, 2.9.2
> Reporter: Raul Kripalani
> Assignee: Raul Kripalani
> Fix For: 2.9.3, 2.10.0
>
>
> When handling synchronous invocations, both JMS reply managers {{TemporaryQueueReplyManager}} and {{PersistentQueueReplyManager}} remove the correlation too late.
> {{ReplyManager.handleReplyMessage}} handles the reply triggering the continuation of the remaining route logic, which may as well contain yet another JMS invocation to exactly the same destination, e.g.:
> {code}
> <route>
> <from uri="direct:hello" />
> <inOut uri="activemq:queue:test" />
> <inOut uri="activemq:queue:test" />
> </route>
> {code}
> As a result, the correlation is not removed from the CorrelationMap until the asynchronous dispatch to the second endpoint has finished and the stack unwinds.
> What's worse is that, due to Camel's re-use of endpoints, both producers are represented as exactly the same Endpoint instance, sharing *the same ReplyManager and CorrelationMap*.
> So during the dispatch to the second endpoint, the correlation is overwritten in the CorrelationMap but, immediately after, the first endpoint removes the correlation anyway!
> Since correlation ID are dragged on (see CAMEL-5390), the route will fail, providing a bad out-of-box experience for such a simple use case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5465) JMS Reply Managers should remove
correlation earlier
Posted by "Raul Kripalani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raul Kripalani updated CAMEL-5465:
----------------------------------
Affects Version/s: (was: 2.10.0)
Fix Version/s: 2.10.0
2.9.3
Assignee: Raul Kripalani
> JMS Reply Managers should remove correlation earlier
> ----------------------------------------------------
>
> Key: CAMEL-5465
> URL: https://issues.apache.org/jira/browse/CAMEL-5465
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
> Affects Versions: 2.8.6, 2.9.2
> Reporter: Raul Kripalani
> Assignee: Raul Kripalani
> Fix For: 2.9.3, 2.10.0
>
>
> When handling synchronous invocations, both JMS reply managers {{TemporaryQueueReplyManager}} and {{PersistentQueueReplyManager}} remove the correlation too late.
> {{ReplyManager.handleReplyMessage}} handles the reply triggering the continuation of the remaining route logic, which may as well contain yet another JMS invocation to exactly the same destination, e.g.:
> {code}
> <route>
> <from uri="direct:hello" />
> <inOut uri="activemq:queue:test" />
> <inOut uri="activemq:queue:test" />
> </route>
> {code}
> As a result, the correlation is not removed from the CorrelationMap until the asynchronous dispatch to the second endpoint has finished and the stack unwinds.
> What's worse is that, due to Camel's re-use of endpoints, both producers are represented as exactly the same Endpoint instance, sharing *the same ReplyManager and CorrelationMap*.
> So during the dispatch to the second endpoint, the correlation is overwritten in the CorrelationMap but, immediately after, the first endpoint removes the correlation anyway!
> Since correlation ID are dragged on (see CAMEL-5390), the route will fail, providing a bad out-of-box experience for such a simple use case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5465) JMS Reply Managers should remove
correlation earlier
Posted by "Raul Kripalani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431939#comment-13431939 ]
Raul Kripalani commented on CAMEL-5465:
---------------------------------------
Was able to trace this back to CAMEL-5309. I was unable to reproduce in latest versions (trunk, 2.10 and 2.9.3), but the problem is still present in branch 2.8.x. The fix in CAMEL-5309 creates one Reply Manager per JMS producer, whereas previously there was only one reply manager shared across all producers with the same endpoint definition (the reply manager was scoped to the endpoint). That was indeed the root cause of the issue.
Since there will be no more 2.8.x releases, there's no point retrofitting for 2.8.x.
> JMS Reply Managers should remove correlation earlier
> ----------------------------------------------------
>
> Key: CAMEL-5465
> URL: https://issues.apache.org/jira/browse/CAMEL-5465
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
> Affects Versions: 2.8.6, 2.9.2
> Reporter: Raul Kripalani
> Assignee: Raul Kripalani
> Fix For: 2.9.3, 2.10.0
>
>
> When handling synchronous invocations, both JMS reply managers {{TemporaryQueueReplyManager}} and {{PersistentQueueReplyManager}} remove the correlation too late.
> {{ReplyManager.handleReplyMessage}} handles the reply triggering the continuation of the remaining route logic, which may as well contain yet another JMS invocation to exactly the same destination, e.g.:
> {code}
> <route>
> <from uri="direct:hello" />
> <inOut uri="activemq:queue:test" />
> <inOut uri="activemq:queue:test" />
> </route>
> {code}
> As a result, the correlation is not removed from the CorrelationMap until the asynchronous dispatch to the second endpoint has finished and the stack unwinds.
> What's worse is that, due to Camel's re-use of endpoints, both producers are represented as exactly the same Endpoint instance, sharing *the same ReplyManager and CorrelationMap*.
> So during the dispatch to the second endpoint, the correlation is overwritten in the CorrelationMap but, immediately after, the first endpoint removes the correlation anyway!
> Since correlation ID are dragged on (see CAMEL-5390), the route will fail, providing a bad out-of-box experience for such a simple use case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5465) JMS Reply Manager is shared across
producers for the same endpoint
Posted by "Raul Kripalani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raul Kripalani updated CAMEL-5465:
----------------------------------
Summary: JMS Reply Manager is shared across producers for the same endpoint (was: JMS Reply Managers should remove correlation earlier)
> JMS Reply Manager is shared across producers for the same endpoint
> ------------------------------------------------------------------
>
> Key: CAMEL-5465
> URL: https://issues.apache.org/jira/browse/CAMEL-5465
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
> Affects Versions: 2.8.6, 2.9.2
> Reporter: Raul Kripalani
> Assignee: Raul Kripalani
> Fix For: 2.9.3, 2.10.0
>
>
> When handling synchronous invocations, both JMS reply managers {{TemporaryQueueReplyManager}} and {{PersistentQueueReplyManager}} remove the correlation too late.
> {{ReplyManager.handleReplyMessage}} handles the reply triggering the continuation of the remaining route logic, which may as well contain yet another JMS invocation to exactly the same destination, e.g.:
> {code}
> <route>
> <from uri="direct:hello" />
> <inOut uri="activemq:queue:test" />
> <inOut uri="activemq:queue:test" />
> </route>
> {code}
> As a result, the correlation is not removed from the CorrelationMap until the asynchronous dispatch to the second endpoint has finished and the stack unwinds.
> What's worse is that, due to Camel's re-use of endpoints, both producers are represented as exactly the same Endpoint instance, sharing *the same ReplyManager and CorrelationMap*.
> So during the dispatch to the second endpoint, the correlation is overwritten in the CorrelationMap but, immediately after, the first endpoint removes the correlation anyway!
> Since correlation ID are dragged on (see CAMEL-5390), the route will fail, providing a bad out-of-box experience for such a simple use case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira