>From my point of view, I'm thinking that if an isolated change - such as the one I am implicitly proposing - makes things *better* (in this case solving the issue that Helen is seeing) and doesn't obviously introduce any new issues, then it appears worthwhile. Trying to reengineer the client to guarantee there are never any deadlocks is more than I would want to take on.
Of the existing JIRAs which I can see are about deadlocks, I think the following is true: QPID-3207 : AMQSession.java close() does not close the consumers with the correct arguments the commit here was rolled back when it caused deadlocks. I'm not sure what the problem statement is here, but I suggest we close "will not fix" this JIRA QPID-3216 : Deadlock between "_lock" (in AMQSession#DisptcherThread) and "_messageDeliveryLock" (in AMQSession.java) this issue only occurred when the (reverted) change from QPID-3207 was applied. As is, nothing that takes the _messageDeliveryLock should subsequently take _lock, so no deadlock here will occur. QPID-3259 : Deadlock on Java client side while closing session when topic operation is unauthorized issue where a synchronous operation times out while blocked against the server generated close (this issue is not addressed by my changes) QPID-4276 : Java client - deadlock on concurrent close of consumer and connection this issue should be fixed by the proposed change (occurs because consumer close acquired MDL and FM in opposite order to connection close) QPID-4574 : [JMS] Deadlock involving _failoverMutex and _messageDeliveryLock this is should be fixed by the proposed change (again issue that MDL and FM were acquired in the opposite order) QPID-4906 : If Session close() or closed() method is invoked while inside onMessage(), they should be excuted after onMessage() has completed. close() behaviour is fixed by the proposed change. closed() no longer acquires MDL, and shouldn't block. QPID-4922 : If Consumer close() method is invoked while inside onMessage(), it should be excuted after onMessage() has completed. The title of this seems incorrect. Moreover after the proposed change I do not believe a deadlock should be possible as long as the consumer being closed in on the same session. Closing a consumer on a different session of the same connection may cause issues. QPID-5117 : Java client deadlocks if connection is closed while onMessage() is creating a session This should be fixed after my proposed change QPID-5118 : [JMS] Deadlock when closing a consumer and calling JMS operatons inside onMessage() on AMQP 0-8/0-9/0-9-1 connection This should be fixed after my proposed change QPID-5119 : [JMS] 3-thread deadlock on pre-AMQP-0-10 connection involving messageDeliveryLock, failover mutex and sessionCreationLock This should be fixed by my proposed change If anyone knows any other JIRAs out there regarding deadlocks it'd be good to look at those too... -- Rob On 9 February 2015 at 15:55, Rajith Muditha Attapattu <[email protected]> wrote: > On Mon, Feb 9, 2015 at 6:15 AM, Robbie Gemmell <[email protected]> > wrote: > > > The main thing I recall from back then is it being hard to > > reason about the impact of such changes and the interaction of the > > various locks due to the way the client threads can enter the > > application space (e.g onMessage, exception listeners) and then > > re-enter the client code while holding an unclear set of locks. > > > > > This was the main reason most of the proposed changes weren't applied. > All though the existing tests were passing, concerns were raised about not > being able to measure the impact. > It was a legitimate concern. > I simply gave up after that and took the alternate approach to helping one > of our customers who could no longer use the qpid client. > > It's great if someone could fix these issues, but I no longer have the > desire nor the bandwidth to look at them again. > > Rajith >
