[
https://issues.apache.org/jira/browse/ZOOKEEPER-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069198#comment-13069198
]
Yang Yang commented on ZOOKEEPER-1131:
--------------------------------------
got it, thanks,
it may help to put more comments/ description of algorithm into the election
code.
this could be useful, but experienced Zookeeper developers may not realize it,
and only new-comers like me
feel the help more clearly.
this probably also helps for future debugging/proof/validation, maybe "assert"
is also helpful
> Transactions can be dropped because leader election uses last committed zxid
> instead of last acknowledged/received zxid
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-1131
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1131
> Project: ZooKeeper
> Issue Type: Bug
> Components: leaderElection, server
> Affects Versions: 3.4.0
> Reporter: Alexander Shraer
>
> Suppose we have 3 servers - A, B, C.
> - A is the leader and it sends 2 proposals.
> - Everyone ack the first proposal, only A and C receive and ack the second
> proposal.
> - A commits the first proposal, and A and B see the commit.
> - A commits the second proposal, but fails before anyone else sees the commit.
> - B and C start leader election.
> - Since servers propose their last committed zxid in leader election, and not
> their last received / acked zxid (this is not being tracked, AFAIK), B will
> be elected as leader since it has seen more commits than C.
> - The last transaction is lost forever even though it has been acked by a
> majority.
> Notice that if C reboots before starting the leader election, this problem
> doesn't happen since it "locally commits" the second proposal updating its
> last committed zxid.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
