[ https://issues.apache.org/jira/browse/OAK-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899710#comment-15899710 ]
Stefan Eissing commented on OAK-4780: ------------------------------------- * I will merge current trunk when you have added your OAK-3070 changes. * Revision.getCurrentTimestamp() will change that to store.getClock().getTime() * {{maxIterations}} is only good for testing, {{maxDuration}} is good when people want to run it in a maintenance window. I know the goal could be to have it run all the time, but {{maxDuration}} is for the fallback. * {{batchDelay}} as factor - interesting. Will do. > VersionGarbageCollector should be able to run incrementally > ----------------------------------------------------------- > > Key: OAK-4780 > URL: https://issues.apache.org/jira/browse/OAK-4780 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, documentmk > Reporter: Julian Reschke > Attachments: leafnodes.diff, leafnodes-v2.diff, leafnodes-v3.diff > > > Right now, the documentmk's version garbage collection runs in several phases. > It first collects the paths of candidate nodes, and only once this has been > successfully finished, starts actually deleting nodes. > This can be a problem when the regularly scheduled garbage collection is > interrupted during the path collection phase, maybe due to other maintenance > tasks. On the next run, the number of paths to be collected will be even > bigger, thus making it even more likely to fail. > We should think about a change in the logic that would allow the GC to run in > chunks; maybe by partitioning the path space by top level directory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)