Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
- Java 1.8.0_20, 1.8.0_192, & 1.8.0_172
- Linux 4.9.0-4-amd64 & 3.10.0-327.13
- qpidd 1.39.0
-
Patch
Description
When a JMS MessageConsumer calls receiveMessage with a timeout, if no message is received during the timeout, BasicMessageConsumer_0_10.getMessageFromQueue() calls the syncDispatchQueue() method. As not the dispatcher thread, the consumer waits on a method local CountDownLatch which should be decremented when the AMQSession.Dispatcher thread calls dispatch().
In the AMQSession.Dispatcher thread, the core loop will stop pulling from the queue to dispatch messages when the connection to the broker is lost (isClosing() becomes true).
In this scenario, the receiveMessage call is waiting forever because the Dispatcher will never call dispatch. This also leaves the Dispatcher thread in an infinite loop (using 100% CPU) waiting to be fully closed.
This can fixed by allowing the AMQSession.Dispatcher to always dispatch remaining queue content to ensure a consumer is not waiting forever (see attached).