zookeeper-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Han (Jira)" <j...@apache.org>
Subject [jira] [Resolved] (ZOOKEEPER-3537) Leader election - Use of out of election messages
Date Mon, 30 Sep 2019 21:23:00 GMT

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Han resolved ZOOKEEPER-3537.
------------------------------------
    Fix Version/s: 3.6.0
       Resolution: Fixed

Issue resolved by pull request 1081
[https://github.com/apache/zookeeper/pull/1081]

> Leader election - Use of out of election messages
> -------------------------------------------------
>
>                 Key: ZOOKEEPER-3537
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3537
>             Project: ZooKeeper
>          Issue Type: Improvement
>            Reporter: Karolos Antoniadis
>            Assignee: Karolos Antoniadis
>            Priority: Trivial
>              Labels: pull-request-available
>             Fix For: 3.6.0
>
>          Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Hello ZooKeeper developers,
> in {{lookForLeader}} in {{FastLeaderElection}} there is the following switch block in
case a notification message {{n}} is received where {{n.state}} is either {{FOLLOWING}} or {{LEADING}} ([https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/FastLeaderElection.java#L1029]).
> {code:java}
> case FOLLOWING:
> case LEADING:
>   /*
>    * Consider all notifications from the same epoch
>    * together.
>    */
>   if (n.electionEpoch == logicalclock.get()) {
>     recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));
>     voteSet = getVoteTracker(recvset, new Vote(n.version, n.leader, n.zxid, n.electionEpoch,
n.peerEpoch, n.state));
>     if (voteSet.hasAllQuorums() && checkLeader(outofelection, n.leader, n.electionEpoch))
{
>       setPeerState(n.leader, voteSet);
>       Vote endVote = new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch);
>       leaveInstance(endVote);
>       return endVote;
>     }
>   }
>   /*
>    * Before joining an established ensemble, verify that
>    * a majority are following the same leader.
>    */
>   outofelection.put(n.sid, new Vote(n.version, n.leader, n.zxid, n.electionEpoch, n.peerEpoch,
n.state));
>   voteSet = getVoteTracker(outofelection, new Vote(n.version, n.leader, n.zxid, n.electionEpoch,
n.peerEpoch, n.state));
>   if (voteSet.hasAllQuorums() && checkLeader(outofelection, n.leader, n.electionEpoch))
{
>     synchronized (this) {
>       logicalclock.set(n.electionEpoch);
>       setPeerState(n.leader, voteSet);
>     }
>     Vote endVote = new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch);
>     leaveInstance(endVote);
>     return endVote;
>   }
>   break;{code}
>  
> We notice that when {{n.electionEpoch == logicalclock.get()}}, votes are being added
into {{recvset}}, however {{checkLeader}} is called immediately afterwards with the votes
in {{outofelection}} as can be seen here ([https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/FastLeaderElection.java#L1037]).
> Checking {{outofelection}} instead of {{recvset}} does not cause any problems.
> If {{checkLeader}} on {{outofelection}} fails, although it would have succeeded in {{recvset}},
{{checkLeader}} succeeds immediately afterwards when the vote is added in {{outofelection}}.
> Still, it seems natural to check for a leader in {{recvSet}} and not in {{outofelection}}. 
> Cheers,
>  Karolos
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message