Hi Robert, Thanks for your patches. Does this mean that the tests in the client module are now passing consistently, or do we still have more to do?
On 23/09/2007, Robert Greig <[EMAIL PROTECTED]> wrote: > > 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 >
