[
https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16774879#comment-16774879
]
Andrei Dulceanu commented on OAK-8071:
--------------------------------------
{quote}Do you remember why this check for the number of available permits was
put in place?
{quote}
AFAICR, this was the only method for determining if a certain commit will be
executed right away or will be queued, because the semaphore was already
acquired.
Regarding your concern about a race condition, I'm not sure how this could
happen. IMO, the worst thing that could happen is that a thread which initially
sees that no permits are available is marked as queued, even though the thread
which acquired the semaphore released it in the mean time (after the if check).
Following this point, only one thread will be able to execute commits (having
already acquired the semaphore).
[~mduerig], WDYT about the reasoning above?
> Logging to detect commits carrying over from previous GC generation can block
> other threads from committing
> -----------------------------------------------------------------------------------------------------------
>
> Key: OAK-8071
> URL: https://issues.apache.org/jira/browse/OAK-8071
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Priority: Blocker
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>
> Add logging / monitoring to detect the situation from OAK-8014.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
