[
https://issues.apache.org/jira/browse/ZOOKEEPER-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405154#comment-13405154
]
Todd Lipcon commented on ZOOKEEPER-1427:
----------------------------------------
The patch looks good to me. Thanks for the new tests, I'll try to pull them
back into HDFS soon.
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?
I think it's fine -- if it is killed before renaming tmp to the final location,
then it also will not have responded to any other process with the "promise".
So it's OK to forget the promise -- ie it wasn't successfully made.
> 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
