Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
3.3.2
-
None
-
Patch Available
Description
The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
If the flow is defined such that:
- during the flow messages are produced and send back to a queue and
- a failover transport is used (which uses a MutexTransport internally) and
- the broker where we enqueue is slow
then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
Proposed patch to follow shortly.