[
https://issues.apache.org/jira/browse/QPID-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8285:
-----------------------------
Summary: [JMS AMQP 0-x] Deadlock during receiveMessage when broker
connecton fails (was: Deadlock during receiveMessage when broker connecton
fails)
> [JMS AMQP 0-x] Deadlock during receiveMessage when broker connecton fails
> -------------------------------------------------------------------------
>
> Key: QPID-8285
> URL: https://issues.apache.org/jira/browse/QPID-8285
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 0-x
> Environment: * 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
> Reporter: Jonathan Beales
> Assignee: Alex Rudyy
> Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
> Attachments: qpid_jms_deaklock.patch
>
>
> 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).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
