[
https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763668#comment-16763668
]
Michael Dürig commented on OAK-8014:
------------------------------------
[~ahanikel], please have a look at my latest changes:
[https://github.com/mduerig/jackrabbit-oak/commits/OAK-8014]
* I incorporated your proposal that encapsulates all logic in {{LockAdaptor}}.
I like this approach as this allows us to selectively use this lock adopter or
a simpler one implementing the old behaviour via a feature flag. Also - with a
bit more refactoring - we should be able to move the {{LockAdaptor
> 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)
