[
https://issues.apache.org/jira/browse/ZOOKEEPER-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405283#comment-13405283
]
Flavio Junqueira commented on ZOOKEEPER-1427:
---------------------------------------------
bq. Say, (Current/accepted)epoch is 3 and the new epoch 4 has updated into
'.tmp' file. Unfortunately after updating the '.tmp' file, zk got killed.
During next startup whether zk server needs to look at the '.tmp' file as it is
having the highest number than the actual epoch?
Servers are not required to complete the recovery phase of the protocol, they
can crash before completing. There is a correctness issue only if a server goes
back to an epoch that it promised not to go back to. It is ok to accept an
epoch and not participating in it.
> Writing to local files is done non-atomically
> ---------------------------------------------
>
> Key: ZOOKEEPER-1427
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1427
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.3
> Reporter: Todd Lipcon
> Assignee: Patrick Hunt
> Priority: Critical
> Fix For: 3.4.4, 3.5.0
>
> Attachments: ZOOKEEPER-1427.patch, ZOOKEEPER-1427.patch,
> ZOOKEEPER-1427_br34.patch, ZOOKEEPER-1427_br34.patch
>
>
> Currently, the writeLongToFile() function opens the file for truncate, writes
> the new data, syncs, and then closes. If the process crashes after opening
> the file but before writing the new data, the file may be left empty, causing
> ZK to "forget" an earlier promise. Instead, it should use RandomAccessFile to
> avoid truncating.
--
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
