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.:
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.