[
https://issues.apache.org/jira/browse/QPID-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036828#comment-13036828
]
Rajith Attapattu commented on QPID-3259:
----------------------------------------
IMO a deadlock is a condition where the threads involved cannot recover from it
(i.e blocked forever).
In this case there is a timeout, which will eventually release the lock.
Technicalities aside, I believe the way to fix this is to untangle the error
handling code.
This can happen in any operation that executes synchronously and wait for an
error.
If we invoke an operation synchronously we always look for an error and then
try to notify it to the connection as well.
On the other hand we also try to notify it directly to the connection.
These two code paths will compete with each other for the locks along the way
(most notably the failover mutex).
IMO if we get an error during a synchronous operation, we should just throw a
JMS Exception that says the session is closed and not worry about reporting it
to the connection (bcos the application already knows about it). This will also
prevent the undesirable effect of closing all the other sessions for this
connection even when there is a clear way of notifying the session is closed.
If this error occurred while being in a passive mode (Ex using a message
listener), then we should definitely notify via the exception listener.
For a connection exception we do have a separate code path to take care of
notifying the connection, so the above proposed change will not have an effect.
> Deadlock on Java client side while closing session when topic operation is
> unauthorized
> ---------------------------------------------------------------------------------------
>
> Key: QPID-3259
> URL: https://issues.apache.org/jira/browse/QPID-3259
> Project: Qpid
> Issue Type: Bug
> Environment: Java client runs into a deadlock when it tries to close
> session when a topic operation (publish/subscribe) is not authorized.
> In this situation AMQConnection (in exceptionReceived) tries to grab failover
> mutext and runs into a lock.
> The other issue in this case is that AMQException.isHardError always returns
> true and hence the connection tried to close all sessions inside
> exceptionReceived method. I think there is something wrong here as an
> unauthorized operation in one session should not lead to closing all other
> sessions.
> Reporter: Danushka Menikkumbura
> Assignee: Rajith Attapattu
> Priority: Critical
> Attachments: QPID-3259-SampleClient, QPID-3259-ThreadDump
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]