[
https://issues.apache.org/jira/browse/OAK-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2603:
---------------------------------
Attachment: OAK-2603.patch
[patch|^OAK-2603.patch] which
# initially collects the paths to be deleted
# Sort using PathComparator
# Uses a PATH_TO_ID transformation before passing the paths to DocumentStore
(which works with ids) for removal
[~mreutegg] Can you review. Initially I thought to implement a ID Comparator on
line of PathComparator. However was not sure about id's based on long path. It
might have still worked because sort first on depth would ensure that parent
end up last in the list.
> Failure in one of the batch in VersionGC might lead to orphaned nodes
> ---------------------------------------------------------------------
>
> Key: OAK-2603
> URL: https://issues.apache.org/jira/browse/OAK-2603
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.1.8, 1.0.13
>
> Attachments: OAK-2603.patch
>
>
> VersionGC logic currently performs deletion of nodes in batches. For GC to
> work properly NodeDocument should always be removed in bottom-up mode i.e.
> parent node should be removed *after* child has been removed
> Currently the GC logic deletes the NodeDocument in undefined order. In such
> mode if one of the batch fails then its possible that parent might have got
> deleted but the child was not deleted.
> Now in next run the child node would not be recognized as a deleted node
> because the commit root would not be found.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
