qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-144) Potential deadlocks during failover
Date Fri, 01 Dec 2006 11:09:21 GMT
    [ http://issues.apache.org/jira/browse/QPID-144?page=comments#action_12454877 ] 
            
Martin Ritchie commented on QPID-144:
-------------------------------------

WRT: makeBrokerConnection 

The makeBrokerConnection does indeed pose a problem with failover but not on its own. The
use of makeBrokerConnection will start the connection process that if it fails will cause
the Failover Thread to handle connection. As can be seen in the AMQConnection constructor
the majority of the method needs to be moved in to a connect() method as it lets the failover
mechanism handle the failover issue.  (It does need to be improved as commented in a //todo
there is a Thread.sleep loop that could be replaced with a wait() notify() mechanism.) 

The other two cases are related to attempting reconnection due to a redirection which are
currently only called as part of the failover mechanism and so should already be wrapped in
FailoverSupport

> Potential deadlocks during failover
> -----------------------------------
>
>                 Key: QPID-144
>                 URL: http://issues.apache.org/jira/browse/QPID-144
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client, Dot Net Client
>            Reporter: Steven Shaw
>
> There's a certain need for "failover safety" in the implemenation of public client api
methods. Any method that blocks for a response frame should be wrapped in a FailoverSupport.
FailoverSupport automates the retrying after catching a FailoverException (a RuntimeException).
> Methods that block waiting for a response frame are now easier to identify because they
all call AMQProtocolHandler.syncWrite() (SyncWrite in the .NET client)
> Currently the only methods employing FailoverSupport are AMQConnection.createSession,
AMQSession.createConsumerImpl and createProducerImpl.
> AMQConnection.createSession has 3 calls to syncWrite so certainly needs to be wrapped
in FailoverSupport. No problem there.
> AMQSession.createConsumerImpl/createProducerImpl neither call syncWrite. Unless there
is some other important way in which they block, they don't really need to be wrapped in the
FailoverSupport. It does no harm however.
> The following methods use syncWrite() but are not wrapped in a FailoverSupport:
>   AMQSession's commit(), rollback(), close()
>   AMQConnection.close() via AMQProtocolHandler.closeConnection()
>   BasicMessageConsumer.close()
> These need to be protected/wrapped in a FailoverSupport. Note that commit() and rollback()
are not currently protected by a lock on failoverMutex either.
> Perhaps StateManager.attainState is the only other method that blocks for "a response
frame". In this case a series of response frames that result in the state changing. The only
use of attainState is in AMQConnection.makeBrokerConnection. It would appear to need to be
wrapped in a FailoverSupport as otherwise the FailoverException will escape. Since this is
failing-over during connection some care may be required. Note that the makeBrokerConnection
is used at 3 different sites.
> In addition sendAcknowledgement appear to need to lock the failoverMutex.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message