zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From afine <...@git.apache.org>
Subject [GitHub] zookeeper pull request #247: ZOOKEEPER-2778: Potential server deadlock betwe...
Date Fri, 19 May 2017 21:47:33 GMT
Github user afine commented on a diff in the pull request:

    https://github.com/apache/zookeeper/pull/247#discussion_r117582004
  
    --- Diff: src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java ---
    @@ -682,27 +682,19 @@ public void setQuorumAddress(InetSocketAddress addr){
         }
     
         public InetSocketAddress getElectionAddress(){
    -        synchronized (QV_LOCK) {
    -            return myElectionAddr;
    -        }
    +        return myElectionAddr;
    --- End diff --
    
    > All set code path was protected by QV_LOCK already, which implies that whoever calls
set* should already acquire the QV_LOCK.
    
    Not sure about this one. `setElectionAddress` is called by `recreateSocketAddresses` which
is called by `QuorumCnxManager#Listener.run` without acquiring QV_LOCK. Not sure what the
implication of this is. Although I believe you are correct about `setClientAddress`.
    
    > if we get out dated addr (in case the current quorum peer is being reconfigured)
and sent this to another peer, another peer will not able to connect but that's fine, it will
retry until at certain point later it will get correct information.
    
    What is the behavior if we are able to connect to the "incorrect peer". Will we eventually
disconnect or do we stay connected until reconfiguration occurs again?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message