[
https://issues.apache.org/jira/browse/ZOOKEEPER-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357615#comment-15357615
]
Ryan Zhang commented on ZOOKEEPER-2461:
---------------------------------------
Here is more info about the sequence.
1. Lost connection to the leader
2016-06-23 16:37:42,408 - WARN
[QuorumPeer[myid=7]/0:0:0:0:0:0:0:0:2181] - Exception when observing the leader
2. The observer started to send election requests (notification)
2016-06-23 16:37:42,501 - INFO [QuorumPeer[myid=7]/0:0:0:0:0:0:0:0:2181] - New
election. My id = 7, proposed zxid=0x8000000000000000
3. The lead election protocol is designed in a way that all the participants
will just reply to that request from an observer with its current vote.
FastLeaderElection.java line 325:
if(!self.getCurrentAndNextConfigVoters().contains(response.sid)) {
By that time, all the participants haven't agreed on the new leader so they all
replied with the old leader.
2016-06-23 16:37:47,531 - INFO [WorkerReceiver[myid=7]] - Notification: 4
(n.leader), 0x1f190441a1 (n.zxid), 0x1 (n.round), LOOKING (n.state), 1 (n.sid),
0x1f (n.peerEPoch), LOOKING (my state)2002b276da (n.config version)
2016-06-23 16:37:47,531 - INFO [WorkerReceiver[myid=7]] - Notification: 4
(n.leader), 0x1f190441a1 (n.zxid), 0x1 (n.round), LOOKING (n.state), 2 (n.sid),
0x1f (n.peerEPoch), LOOKING (my state)2002b276da (n.config version)
2016-06-23 16:37:47,531 - INFO [WorkerReceiver[myid=7]] - Notification: 4
(n.leader), 0x1f190441a1 (n.zxid), 0x1 (n.round), LOOKING (n.state), 3 (n.sid),
0x1f (n.peerEPoch), LOOKING (my state)2002b276da (n.config version)
2016-06-23 16:37:52,537 - INFO [WorkerReceiver[myid=7]] - Notification: 4
(n.leader), 0x1f190441a1 (n.zxid), 0x1 (n.round), LOOKING (n.state), 0 (n.sid),
0x1f (n.peerEPoch), LOOKING (my state)2002b276da (n.config version)
4. This is enough for the observer to have a quorum so the observer again pick
sid 4.
The last step is the part I am not sure is optimal. As far as I can see, the
votes all indicate that the peer are in "LOOKING" state. I wonder why should an
observer consider those vote and spend time connecting to a false leader which
can take up to initLimitTime to give up. Why not wait till the quorum is
formed? Basically the same algorithm but filter out the vote from the "LOOKING"
participants.
Any thoughts?
> There is no difference between the observer and the participants in the
> leader election algorithm
> -------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-2461
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2461
> Project: ZooKeeper
> Issue Type: Improvement
> Components: quorum
> Affects Versions: 3.5.0
> Reporter: Ryan Zhang
> Assignee: Ryan Zhang
> Fix For: 3.4.9, 3.5.3, 3.6.0
>
>
> We have observed a case that when a leader machine crashes hard, non-voting
> learners take a long time to detect the new leader. After looking at the
> details more carefully, we identified one potential improvement (and one bug
> fixed in the 3.5).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
