[ https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16765857#comment-16765857 ]
Michael Dürig commented on OAK-8014: ------------------------------------ The reason I didn't mention rebase is because that term is already used for rebasing changes in a {{NodeBuilder}} on top of the latest head state. See {{org.apache.jackrabbit.oak.spi.state.NodeStore#rebase}}. In the case of a calling {{writeAhead}} what really happens is that the entire node state might get rewritten to avoid referencing records from previous revisions that live in segments of a previous gc generation. Maybe we can make this aspect more clear though!? > 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)