CXF JMS transport with request-reply messaging deletes temporary queues whilst messages are still in flight

An application uses the CXF SOAP/JMS transport in a request-reply pattern. The default behaviour with this pattern is to create a temporary queue, and use that temporary queue for multiple messages consumed from the same endpoint. Correlation IDs are used to match up requests and replies.

Consider a situation where multiple request-reply exchanges are in flight, using the same temporary queue. If one of those exchanges times out, and exception is raised in the CXF JMS transport. This causes the temporary queue to be deleted (perhaps, but not certainly, because the underlying TCP connection is closed).

A new temporary queue gets created but, by that time, all the in-flight messages fail, because the destination no longer has a replace to reply to – the temporary queue it should have replied to no longer exists. The consequence is that a minor problem is turned into a major problem, with substantial message loss.