[
https://issues.apache.org/jira/browse/OAK-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14108992#comment-14108992
]
Michael Dürig commented on OAK-2045:
------------------------------------
bq. The problem with CompactionMap based approach is that we need to maintain
the map state (for still living SegmentId) across all the cleanup operations.
And if the segmentId got shifted multiple times then track it all along. Given
that path looks more stable
That's no better with the path. Only that here that information is right in the
node state instead in a separate place. So in the end I don't see much of a
difference except for the path to take up too much space. This *will* create
issues.
bq. One way or the other this contract would be broken under this approach
Which is a clear indication to me that we should rethink the approach. Breaking
the equality contract for node states will haunt us forever.
What we probably need to do is to use a virtualised address space: currently
the record id points directly to the storage location. By making this a virtual
address and going through a mapping, different generations could use different
mappings without breaking fundamental contracts..
> Long running JCR session prevent live cleanup in Segment FileStore
> ------------------------------------------------------------------
>
> Key: OAK-2045
> URL: https://issues.apache.org/jira/browse/OAK-2045
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.1
>
> Attachments: OAK-2045-segment-fault-approach.patch,
> OAK-2045-test-fix.patch
>
>
> Cleanup operation in SegmentNodeStore detects the un referenced garbage and
> clean it up. To determine the reference validity it starts with an initial
> set of SegmentId which have a live java reference.
> This works fine for simple setup but when Oak repository is used in an
> application (like Sling) where application code can create long running
> session (for observation) then such session are bound to old NodeState at
> time of startup. Such references prevent the cleanup logic to remove older
> revisions while system is running. Such revisions can only be removed via an
> offline compaction-> cleanup.
> Need to find out a way where we can _migrate_ such old NodeState references
> to newer revisions
--
This message was sent by Atlassian JIRA
(v6.2#6252)
