jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2819) FileDataStore not crash safe
Date Mon, 06 Dec 2010 08:46:11 GMT

    [ https://issues.apache.org/jira/browse/JCR-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12967123#action_12967123
] 

Thomas Mueller commented on JCR-2819:
-------------------------------------

> it sounds like it is only covering the "close/rename(replace)" not "close/rename(new)"
case

I'm not sure about that... But anyway, the FileDataStore should have such a feature. I don't
think it should be enabled by default, but let's see. There are multiple options: 1) FileOutputStream.getFD().sync()
and 2) FileOutputStream.getChannel().force(boolean metaData). Also related is: 3) new RandomAccess(..,
"rwd" / "rws") - but that would be a bigger change because FileOutputStream doesn't support
this. I suggest we support 1) and 2) but not 3), and add a option "syncMethod" (setSyncMethod(String
value)): 

- "" (empty string, default) for current behavior
- "sync" for FileOutputStream.getFD().sync()
- "force" for FileOutputStream.getChannel().force(true)
- "forceFalse" for FileOutputStream.getChannel().force(false)

Could you create such a patch? If not, I will create it (but it will take some time...)

> FileDataStore not crash safe
> ----------------------------
>
>                 Key: JCR-2819
>                 URL: https://issues.apache.org/jira/browse/JCR-2819
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.1.2
>         Environment: All
>            Reporter: Bernd Eckenfels
>            Priority: Minor
>         Attachments: FileDataStore.patch
>
>
> The FileDataStore.addRecord() does create a temporary file and rename it to the final
location. On a crash, this can result in a file which is renamed but the content is still
empty. This especially happens on systems where data in the filesystem is not journaled. You
can resolve this problem by calling the fdsync() method of the operating system before renaming
the file. Typically in Java this is done by first flushing all the Java buffers (i.e. calling
flush() on the highest output stream), and then using the getFD().sync(); method on the FileOutputStream.
> Note: this introduced some delay/additional IO load on the system, therefore I think
it might be best to make it configurable. But I think in some environments the additional
reliability is badly needed.
> Sample patch without configuration parameter added.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message