[
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.
