[ https://issues.apache.org/jira/browse/ZOOKEEPER-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306144#comment-16306144 ]
ASF GitHub Bot commented on ZOOKEEPER-2959: ------------------------------------------- GitHub user xyq000 opened a pull request: https://github.com/apache/zookeeper/pull/438 ZOOKEEPER-2959: ignore accepted epoch and ack from observers https://issues.apache.org/jira/browse/ZOOKEEPER-2959 After a round of elections completes, followers and observers send their accepted epochs to the leader to determine a final epoch. Since `QuorumVerifier#containsQuorum(Set set)` does not check whether the elements of argument `set` exactly represent participants, this pull request is intended to ignore reported epochs and acks from observers for logical consistency. You can merge this pull request into a Git repository by running: $ git pull https://github.com/xyq000/zookeeper ZOOKEEPER-2959 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/zookeeper/pull/438.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #438 ---- commit 647061aa7ba1182b83b44b7f2671508012a30b4c Author: Yongqiang Xiang <xiangyongqiang@...> Date: 2017-12-29T08:20:06Z ignore accepted epoch and ack from observers ---- > ignore epoch proposal and ack from observers when a newly elected leader > computes new epoch > ------------------------------------------------------------------------------------------- > > Key: ZOOKEEPER-2959 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2959 > Project: ZooKeeper > Issue Type: Bug > Affects Versions: 3.4.10, 3.5.3 > Reporter: xiangyq000 > > Once the ZooKeeper cluster finishes the election for new leader, all learners > report their accepted epoch to the leader for the computation of new cluster > epoch. > org.apache.zookeeper.server.quorum.Leader#getEpochToPropose > {code:java} > private final HashSet<Long> connectingFollowers = new HashSet<Long>(); > public long getEpochToPropose(long sid, long lastAcceptedEpoch) throws > InterruptedException, IOException { > synchronized(connectingFollowers) { > if (!waitingForNewEpoch) { > return epoch; > } > if (lastAcceptedEpoch >= epoch) { > epoch = lastAcceptedEpoch+1; > } > connectingFollowers.add(sid); > QuorumVerifier verifier = self.getQuorumVerifier(); > if (connectingFollowers.contains(self.getId()) && > > verifier.containsQuorum(connectingFollowers)) { > waitingForNewEpoch = false; > self.setAcceptedEpoch(epoch); > connectingFollowers.notifyAll(); > } else { > long start = Time.currentElapsedTime(); > long cur = start; > long end = start + self.getInitLimit()*self.getTickTime(); > while(waitingForNewEpoch && cur < end) { > connectingFollowers.wait(end - cur); > cur = Time.currentElapsedTime(); > } > if (waitingForNewEpoch) { > throw new InterruptedException("Timeout while waiting for > epoch from quorum"); > } > } > return epoch; > } > } > {code} > The computation will get an outcome once : > # The leader has call method "getEpochToPropose" > # The number of all reporters is greater than half of participants. > The problem is, an observer server will also send its accepted epoch to the > leader, while this procedure treat observers as participants. > Supposed that the cluster consists of 1 leader, 2 followers and 1 observer, > and now the leader and the observer have reported their accepted epochs while > neither of the followers has. Thus, the connectingFollowers set consists of > two elements, resulting in a size of 2, which is greater than half quorum, > namely, 2. Then QuorumVerifier#containsQuorum will return true, because it > does not check whether the elements of the parameter are participants. > The same flaw exists in > org.apache.zookeeper.server.quorum.Leader#waitForEpochAck -- This message was sent by Atlassian JIRA (v6.4.14#64029)