[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406177#comment-13406177
 ] 

Patrick Hunt commented on ZOOKEEPER-1427:
-----------------------------------------

Thanks for the feedback Rakesh/Todd/Flavio.

bq. it might be a good idea to make sure that the server doesn't make further 
progress if the write disk fail

Using Eclipse I backtracked the calls to the atomic operation. It branches 
quickly, but from what I can see any exceptions thrown when writing the file 
are handled properly.

bq. Is there any case in zookeeper to look at the '.tmp' file while reading 
back?

I think the comments clarified this. But basically the server never tries to 
read the .tmp file, it will only write that file and eventually do the rename. 
If the rename occurs we're done, if the rename fails we attempt to remove the 
.tmp file, regardless we ignore that file outside of the atomicoutputstream 
named file creation process. (so I think we're good)

bq. You may also want to raise the level of the log message to error in the 
catch block.

I'll submit an updated patch for this.


                
> 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

        

Reply via email to