Mahadev konar resolved ZOOKEEPER-313.

    Resolution: Duplicate
      Assignee: Mahadev konar


i am makring this as a duplicate of ZOOKEEPER-251. I have openened 
ZOOKEEPER-335 for logging the new leader election txn. 
Please feel free to reopen if that is not the case.

> Problem with successive leader failures when no client is connected 
> --------------------------------------------------------------------
>                 Key: ZOOKEEPER-313
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-313
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.0.0, 3.0.1
>         Environment: all
>            Reporter: Sunanda Bera
>            Assignee: Mahadev konar
>             Fix For: 3.1.1
> Steps to reproduce:
> Create a 3 node cluster . Run some transactions and then stop all clients. 
> Make sure no other clients connect for the duration of the test.
> Let L1 be the current leader. Bring down L1. Let L2 be the leader chosen.  
> Let the third node be N3. Note that this will increase the txn id for N3's 
> snapshot without any  transaction being logged. Now bring up L1 -- same will 
> happen for L1. Now bring down L2.
> Both N3 and L1 now have snapshots with a transaction id greater than the last 
> logged transaction. Whoever is elected leader will try to restore its state 
> from the filesystem and fail.
> One easy workaround is obviously to change the FileTxnSnapLog not to save a 
> snapshot if zxid > last logged zxid. The correct solution is possibly to log 
> a transaction for leader election as well.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to