On 22/09/2007, Robert Greig <[EMAIL PROTECTED]> wrote: > I managed to get a threaddump and it shows yet another deadlock > involving the dispatcher. Details are attached to QPID-589.
Looking at the deadlock, it occurs because during session close, it sends Basic.Cancel for each consumer, and the Basic.Cancel-Ok handler (on a separate thread) calls Dispatcher.rejectPending which in turn tries to acquire the dispatcher lock. Sadly the dispatcher lock is already held by dispatcher.run(). Dispatcher.run is trying to acquire the messageDeliveryLock, which is already held by the close method is AMQSession. I couldn't spot an obvious solution involving reordering of locks. However it did occur to me that it was not necessary to send a Basic.Cancel where we are about to close the entire session (AMQP channel). Does anyone disagree and think we have to send Basic.Cancel? I have committed a change to the M2 branch so that it does not send Basic.Cancel where the session is closing and so far on our continuous build there have been no test failures or deadlocks. If it turns out that someone knows why we must send Basic.Cancel then I will obviously back out that change. RG
