[
https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755882#comment-16755882
]
Francesco Mari commented on OAK-8014:
-------------------------------------
[~mduerig], the patch proves the point and should fix the observed behaviour. I
think it's perfectly safe to move the call to {{changes.getNodeState()}}
outside the lock.
> 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.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)
