[
https://issues.apache.org/jira/browse/JCR-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888777#action_12888777
]
Peter Dettman commented on JCR-2674:
------------------------------------
1. My feeling is that "if (file.lastModified() < now + ACCESS_TIME_RESOLUTION)"
is not necessary, since the lastModified value will already be truncated to the
system resolution, but I do not think it is harmful.
2. I chose to throw exception only if file.canWrite, because I was trying to
minimise the impact of the change. It's not clear to me whether setLastModified
might work when !file.canWrite. However, it certainly must work (because of GC)
if file.canWrite. I would consider moving the canWrite test outside of the
setLastModified call, similar to getRecordIfStored, it just wasn't necessary to
fix the immediate problem.
3. Well, not swallowed exactly, but caught and converted to failure return code
(-1) e.g. see BLOBInDataStore.getSize. In any case, the javadoc for
Property.getLength/getLengths documents -1 as a possible "failure" return code,
so it had to be tested. I think if Property.getLength/getLengths throws an
exception, that is already correctly handled.
Thanks for the quick response.
> 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
> Fix For: 2.2.0
>
> 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.
