[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070623#comment-13070623
 ] 

Vishal K commented on ZOOKEEPER-1131:
-------------------------------------

Hi Alex

{quote}
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.
{quote}

Before returning zkDb.getDataTreeLastProcessedZxid(), FileTnxSnapLog.restore() 
would be called which deserializes the snapshot and also applies (to the data 
tree) any pending transactions from the transaction log. This should set the 
lastProcessedZxid in the DataTree correctly.

> 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

        

Reply via email to