[ https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763733#comment-16763733 ]
Michael Dürig commented on OAK-8014: ------------------------------------ In the meanwhile I * Further decoupled {{LockAdapter}} from the rest of the code. * Moved {{LockAdapter}} to a top level class Next steps * Document pre-, post-conditions and invariants of the lock and implement unit tests for them * Factor out its interface so we can implement another variant resembling the old behaviour. This allows us to selectively test {{LockAdapter}} without impacting others should we have overseen something. > Commits carrying over from previous GC generation can block other threads > from committing > ----------------------------------------------------------------------------------------- > > Key: OAK-8014 > URL: https://issues.apache.org/jira/browse/OAK-8014 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar > Affects Versions: 1.10.0, 1.8.11 > Reporter: Michael Dürig > Assignee: Michael Dürig > Priority: Blocker > Labels: TarMK > Fix For: 1.12, 1.11.0, 1.8.12 > > Attachments: OAK-8014.patch > > > A commit that is based on a previous (full) generation can block other > commits from progressing for a long time. This happens because such a commit > will do a deep copy of its state to avoid linking to old segments (see > OAK-3348). Most of the deep copying is usually avoided by the deduplication > caches. However, in cases where the cache hit rate is not good enough we have > seen deep copy operations up to several minutes. Sometimes this deep copy > operation happens inside the commit lock of > {{LockBasedScheduler.schedule()}}, which then causes all other commits to > become blocked. > cc [~rma61...@adobe.com], [~edivad] -- This message was sent by Atlassian JIRA (v7.6.3#76005)