[
https://issues.apache.org/jira/browse/ZOOKEEPER-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230767#comment-14230767
]
Alexander Shraer commented on ZOOKEEPER-2076:
---------------------------------------------
In Leader.java look for "designatedLeader" - this is where the old leader
chooses and announces its replacement.
Then Follower.java and Observer.java get this message (also look for
designatedleader) and call QuorumPeer.processReconfig() which gets
suggestedLeaderId as parameter. Notice the updateVote there.
Then the follower throws an exception (because its a major change) and
QuorumPeer goes into LOOKING state,
which invokes FastLeaderElection, and here is where the initial vote set
earlier is used, so they all initially vote for the designated leader, which is
supposed to converge quickly.
> Improve Leader Change Mechanism
> -------------------------------
>
> Key: ZOOKEEPER-2076
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2076
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.5.0
> Reporter: Alexander Shraer
>
> When a leader is removed during a reconfiguration, ZOOKEEPER-107 uses a
> mechanism where the old leader nominates the new one. Although it reduces the
> time for a new leader to be elected, it still takes too long. This JIRA is
> for two things:
> 1. Improve the mechanism, e.g., avoid loading snapshots, etc. during the
> handoff.
> 2. Make it a first-class citizen & export it as a client API. We get
> questions about this once in a while - how do I cause a different leader to
> be elected ? Currently the response is either kill or reconfigure the current
> leader.
> Any one interested to work on this ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
