[
https://issues.apache.org/jira/browse/ZOOKEEPER-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910643#action_12910643
]
Benjamin Reed commented on ZOOKEEPER-869:
-----------------------------------------
this is a good observation diogo, but i think you may be characterizing it
improperly. the problem is that when we do a leadership we increment the epoch
and propose a new leader, so all other processes will be much lower than the
leader. when a follower connects we figure out how far behind the follower is
by comparing the lastProposed zxids and taking the difference. we should really
be using the recent history to do the comparison.
as a side note, if we were to chose not to take the maximum zxid during
recovery, we need to make sure that we still cover all committed messages.
> Support for election of leader with arbitrary zxid
> --------------------------------------------------
>
> Key: ZOOKEEPER-869
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-869
> Project: Zookeeper
> Issue Type: New Feature
> Reporter: Diogo
> Priority: Minor
>
> Currently, the leader election algorithm implemented guarantees that the
> leader has the maximum zxid of the ensemble. The state synchronization after
> the election was built based on this assumption. However, other leader
> elections algorithms might elect leaders with arbitrary zxid.
> To support other leader election algorithms, the state synchronization should
> allow the leader to have an arbitrary zxid.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
