zookeeper-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "tom.long (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ZOOKEEPER-3481) The problem of AcceptedEpoch
Date Wed, 31 Jul 2019 08:38:00 GMT
tom.long created ZOOKEEPER-3481:
-----------------------------------

             Summary: The problem of AcceptedEpoch
                 Key: ZOOKEEPER-3481
                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3481
             Project: ZooKeeper
          Issue Type: Improvement
          Components: quorum
    Affects Versions: 3.5.5
            Reporter: tom.long
            Assignee: Andor Molnar
             Fix For: 3.5.6


If the leader has been elected when the voting participant joins the cluster, then it can
only act as followers. When getepochtoveto is called, it does not participate in the voting.
However, if the AcceptedEpoch is larger than the leader, it will never work properly.The status
is as follows:LOOKING -> FOLLOWING -> exception -> LOOKING.

code as follows(Learner.registerWithLeader(int pktType)):

if (newEpoch > self.getAcceptedEpoch()) {
 wrappedEpochBytes.putInt((int)self.getCurrentEpoch());
 self.setAcceptedEpoch(newEpoch);
} else if (newEpoch == self.getAcceptedEpoch()) {
 // since we have already acked an epoch equal to the leaders, we cannot ack
 // again, but we still need to send our lastZxid to the leader so that we can
 // sync with it if it does assume leadership of the epoch.
 // the -1 indicates that this reply should not count as an ack for the new epoch
 wrappedEpochBytes.putInt(-1);
} else {
 throw new IOException("Leaders epoch, " + newEpoch + " is less than accepted epoch, " + self.getAcceptedEpoch());
}

 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Mime
View raw message