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-2674) FileDataStore ignores return code from setLastModified
Date Thu, 15 Jul 2010 10:14:55 GMT

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

Thomas Mueller commented on JCR-2674:
-------------------------------------

Thanks a lot for the patch! It is now committed (in the trunk only so far). I made an additional
change in addRecord: currently it's "if (file.lastModified() < now)" - I will change that
to "if (file.lastModified() < now + ACCESS_TIME_RESOLUTION)".

Again about addRecord: your code only throws an exception if file.canWrite() returns true
- is that for read-only file systems / access rights? Or does it have a different reason?

> check for -1 return value from Property.getLength

You mean the exception from FileDataStore.getRecordIfStored() is swallowed? That's wouldn't
be nice. Anyway, your change is OK.

> 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
>            Assignee: Thomas Mueller
>            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.


Mime
View raw message