You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Peter Dettman (JIRA)" <ji...@apache.org> on 2010/07/14 21:10:54 UTC

[jira] Updated: (JCR-2674) FileDataStore ignores return code from setLastModified

     [ https://issues.apache.org/jira/browse/JCR-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Dettman updated JCR-2674:
-------------------------------

    Attachment: JCR-2674.patch

Patch modifies FileDataStore to check the return value from setLastModified as appropriate (raises an exception if it failed), and makes sure ACCESS_TIME_RESOLUTION is used in addRecord.

Also modifies GarbageCollector to check for -1 return value from Property.getLength since exceptions don't necessarily propagate.


> FileDataStore ignores return code from setLastModified
> ------------------------------------------------------
>
>                 Key: JCR-2674
>                 URL: https://issues.apache.org/jira/browse/JCR-2674
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.1.0
>         Environment: Solaris/ZFS/JDK1.6.0_20
>            Reporter: Peter Dettman
>            Priority: Critical
>         Attachments: JCR-2674.patch
>
>
> Garbage collection depends on the file modification date being successfully updated when records are "touched" during the mark phase. The result of a silent failure is the catastrophic loss of the file in the sweep phase.
> FileDataStore.getRecordIfStored does not, however, check the return code from setLastModified.
> I believe I was bitten by this when my dev deployment ran out of disk space. A substantial portion of my datastore was deleted, and the best explanation I can come up with is that the setLastModified calls started (silently) failing, leading to massive overkill in the sweep.
> There is also a call to setLastModified in FileDataStore.addRecord which is not strictly correct in the face of GC (i.e. it needs the resolution offset, and also must succeed if the file is writable or risk incorrect collection).
> Patch to follow.

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