jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-8014) Commits carrying over from previous GC generation can block other threads from committing
Date Fri, 08 Feb 2019 15:03:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763669#comment-16763669
] 

Michael Dürig edited comment on OAK-8014 at 2/8/19 3:02 PM:
------------------------------------------------------------

[~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 adapter 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 {{LockAdapter}} to its own file and unit test it independently. To this respect
I will try to come up with a list of properties we require from the implementation and that
should be covered by the unit test.
 * There was still a problem that could cause a deadlock between threads owning the {{LockAdapter}}'s
instance monitor waiting for {{tryLock}} and other threads waiting for {{unlock}}. To overcome
this I had to move some code from {{lockAfterRefresh}} into the synchronized method {{tryLock}}
and at the same time switch the order of the two statements 

{code:java}
this.generation = generation;
unlock.set(this::release);
{code}
this bit is crucial as it ensures that whenever {{release}} is called the generation was set
correctly.


was (Author: mduerig):
[~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 [~rma61870@adobe.com], [~edivad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message