[ 
https://issues.apache.org/jira/browse/OAK-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930035#comment-15930035
 ] 

Julian Reschke commented on OAK-4780:
-------------------------------------

bq. At the end of all iterations, the VersionGarbageCollector returns a 
VersionGCStats that accumulates data from all iterations made. Only the 
stopwatches are currently not, as Stopwatch lacks methods to add time from 
other watches. And re-using the same instances in each iteration will show the 
incorrect data for each iteration. 

The code below works (for some value of "works"):

{noformat}
    public static void main(String[] args) throws InterruptedException {

        final Stopwatch w1 =Stopwatch.createStarted();
        Thread.sleep(123);
        w1.stop();
        System.out.println(w1);

        final Stopwatch w2 =Stopwatch.createStarted();
        Thread.sleep(456);
        w2.stop();
        System.out.println(w2);

        Stopwatch sum = Stopwatch.createStarted(new Ticker() {

            private boolean calledOnce = false;
            @Override
            public long read() {
                if (calledOnce) {
                    return w1.elapsed(TimeUnit.MILLISECONDS) + 
w2.elapsed(TimeUnit.MILLISECONDS);
                }
                else {
                    calledOnce = true;
                    return 0;
                }
            }
        });
        sum.stop();
        System.out.println(sum);
    }
{noformat}

> 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)

Reply via email to