[ https://issues.apache.org/jira/browse/ZOOKEEPER-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400160#comment-13400160 ]
Marshall McMullen commented on ZOOKEEPER-1453: ---------------------------------------------- I'm running trunk revision 1339307, and it looks like ZOOKEEPER-1156 is included therein. So I think that I'm OK with regard to that particular bug. You bring up a very valid point. I hadn't thought about pinpointing why we are seeing this corruption, only that we are and trying to prevent it from causing that node to not re-join the ensemble when it comes back up. The next time this happens I'll grab log files and a copy of the datadir. Thanks! > corrupted logs may not be correctly identified by FileTxnIterator > ----------------------------------------------------------------- > > Key: ZOOKEEPER-1453 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1453 > Project: ZooKeeper > Issue Type: Bug > Components: server > Affects Versions: 3.3.3 > Reporter: Patrick Hunt > Priority: Critical > > See ZOOKEEPER-1449 for background on this issue. The main problem is that > during server recovery > org.apache.zookeeper.server.persistence.FileTxnLog.FileTxnIterator.next() > does not indicate if the available logs are valid or not. In some cases (say > a truncated record and a single txnlog in the datadir) we will not detect > that the file is corrupt, vs reaching the end of the file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira