Robbie Gemmell commented on QPIDJMS-446:

QPIDJMS is only the Jira project for the newer AMQP 1.0 JMS client. I'll move 
this issue to the QPID Jira project used for the older AMQP 0-x client if I 
can, or close it if not.

> Deadlock during receiveMessage when broker connecton fails
> ----------------------------------------------------------
>                 Key: QPIDJMS-446
>                 URL: https://issues.apache.org/jira/browse/QPIDJMS-446
>             Project: Qpid JMS
>          Issue Type: Bug
>          Components: qpid-jms-client
>         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
>            Priority: Major
>         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

To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to