[ https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771153#comment-16771153 ]
Axel Hanikel commented on OAK-8014: ----------------------------------- [~mduerig] Don't we have to also check the underlying lock in LockFixture#assertUnlock? As in https://github.com/ahanikel/jackrabbit-oak/commit/bfe93a0d922c8942209da1ab1d25f700477e1deb > 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)