[
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