[jira] [Updated] (OAK-2358) revisionGC leaves garbage around, for often-changed nodes

["Stefan Egli (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Egli updated OAK-2358:
-----------------------------
    Attachment: RevisionGCTest.java

Attaching a test to reproduce the growing number of garbage-revisions - it's written in 'benchmark-style' - could probably be changed to a plain JUnit though. But running this test and monitoring mongo shows that the #split documents of /test increases slowly over time. Running the same test with doing gc every 5 iterations (vs 50 with which it is attached now) runs fine though - which indicates that revisionGC doesn't handle split documents correctly

> revisionGC leaves garbage around, for often-changed nodes
> ---------------------------------------------------------
>
>                 Key: OAK-2358
>                 URL: https://issues.apache.org/jira/browse/OAK-2358
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.0.8
>         Environment: 1.0.8.r1644758
>            Reporter: Stefan Egli
>            Priority: Critical
>         Attachments: RevisionGCTest.java
>
>
> With oak-core 1.0.8.r1644758 we're seeing revision garbage piling up - even though revisionGC runs regularly (every night) and does not complain about any failures.
> This happens with often-changed nodes, ie with nodes that get more changes that fit into a mongo document, thus get split between revisionGC-runs.
> As a negative side-effect of this, the observation event generating (ie diffImpl) seems to have problems with such revision garbage and performs tremendously slow - presumably because all garbage-revisions are read even though the diff should be very small (ie the fromRev/toRev are only a few seconds, if ever minutes apart) - but I'll file a separate ticket about this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)