Hadoop QA commented on ZOOKEEPER-582:

-1 overall.  Here are the results of testing the latest attachment 
  against trunk revision 881882.

    +1 @author.  The patch does not contain any @author tags.

    +1 tests included.  The patch appears to include 9 new or modified tests.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    +1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

    +1 findbugs.  The patch does not introduce any new Findbugs warnings.

    +1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

    -1 core tests.  The patch failed core unit tests.

    +1 contrib tests.  The patch passed contrib unit tests.

Test results: 
Findbugs warnings: 
Console output: 

This message is automatically generated.

> ZooKeeper can revert to old data when a snapshot is created outside of normal 
> processing
> ----------------------------------------------------------------------------------------
>                 Key: ZOOKEEPER-582
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-582
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.1.1, 3.2.1
>            Reporter: Benjamin Reed
>            Priority: Blocker
>             Fix For: 3.2.2, 3.1.2
>         Attachments: test.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, 
> ZOOKEEPER-582_3.1.patch, ZOOKEEPER-582_3.2.patch
> when zookeeper starts up it will restore the most recent state (latest zxid) 
> it finds in the data directory. unfortunately, in the quorum version of 
> zookeeper updates are logged using an epoch based on the latest log file in a 
> directory. if there is a snapshot with a higher epoch than the log files, the 
> zookeeper server will start logging using an epoch one higher than the 
> highest log file.
> so if a data directory has a snapshot with an epoch of 27 and there are no 
> log files, zookeeper will start logging changes using epoch 1. if the cluster 
> restarts the state will be restored from the snapshot with the epoch of 27, 
> which in effect, restores old data.
> normal operation of zookeeper will never result in this situation.
> this does not effect standalone zookeeper.
> a fix should make sure to use an epoch one higher than the current state, 
> whether it comes from the snapshot or log, and should include a sanity check 
> to make sure that a follower never connects to a leader that has a lower 
> epoch than its own.

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