Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Duplicate
-
2.8.6, 2.9.2
-
None
-
Unknown
Description
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.:
<route> <from uri="direct:hello" /> <inOut uri="activemq:queue:test" /> <inOut uri="activemq:queue:test" /> </route>
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.
Attachments
Issue Links
- is broken by
-
CAMEL-5309 Replies with Incorrect CorrelationIDs Received After Reinstantiating a Route with ActiveMQ Endpoint and Exclusive Reply Queue
-
- Resolved
-