[
https://issues.apache.org/jira/browse/OAK-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356456#comment-14356456
]
Chetan Mehrotra commented on OAK-2603:
--------------------------------------
bq. I noticed one minor thing: the debug message mentions ids, but now passes
paths. We should either change the message or transform the paths to ids.
Ack
bq. I was also wondering if the partitioning is necessary because we already do
that in the MongoDocumentStore.remove().
The problem is that remove takes a list and not iterator currently. Creating a
complete new list post transformation would have doubled the storage cost. So
used current approach. This would also be later required for fix done for
OAK-2557
> 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)
