On Mon, 2008-03-03 at 12:03 +0100, Arnaud Simon wrote: > Rafael is absolutely right, Session.close is holding a lock on > _messageDeliveryLock only to prevent messages being delivered to > consumers when the session is closing (note that this lock should also > be held when consumer are closing, see Qpid-812). There is however no > reason for the dispatcher thread to keep a lock on _lock when > dispatching a message. _lock is used for stopping/starting the > dispatcher thread and _messageDeliveryLock for preventing message > delivery. So, we should change the run method of dispatcher for > releasing _lock and rollback and rejectPending for synchronizing on > _messageDeliveryLock.
> Note that this deadlock situation would not happen with 0.8 as an > external thread is calling rejectPending but (if the dispatcher is > trying to dispatch a message) this thread will need to wait until > close > finishes and will create a new dispatcher thread that will not be > closed. I was wrong actually the deadlock exists but the close operation will eventually throw an exception as the synchronous operation sendCancel is timing out.
