[
https://issues.apache.org/jira/browse/ZOOKEEPER-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070827#comment-13070827
]
Alexander Shraer commented on ZOOKEEPER-1131:
---------------------------------------------
yeah, seems that way. Sorry, it was my mistake, I'm closing the bug.
> 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 which have seen the same number of
> commits.
> - A is the leader and it sends out a new proposal.
> - B doesn't receive the proposal, but A and C receive and ACK it
> - A commits the proposal, but fails before anyone else sees the commit.
> - B and C start leader election.
> - since both B and C saw the same number of commits, if B has a higher
> server-id than C, leader election will elect B. Then, the last transaction
> will be truncated from C's log, which is a bug since it was acked by a
> majority.
>
> This happens since servers propose their last committed zxid in leader
> election, and not their last received / acked zxid (this is not being
> tracked, AFAIK). See method
> FastLeaderElection.getInitLastLoggedZxid(), which calls
> QuorumPeer.getLastLoggedZxid(), which is supposed to return the last logged
> Zxid, but instead calls zkDb.getDataTreeLastProcessedZxid() which returns the
> last committed zxid.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
