[
https://issues.apache.org/jira/browse/OAK-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4532.
--------------------------------
bulk close after 1.5.5 release
> race-condition in commit-rate-limiter
> -------------------------------------
>
> Key: OAK-4532
> URL: https://issues.apache.org/jira/browse/OAK-4532
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.5.4
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Fix For: 1.5.5
>
>
> [CommitRateLimiter.delay|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.5.4/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/CommitRateLimiter.java#L81]
> has a race-condition when the queue length drops below thres-hold right when
> {{delay()}} is called. Consider the following steps:
> * thread T1 enters {{delay()}} with a positive value for {{delay}} but gets
> paused right after the check for {{delay>0}}
> * thread T2 enters {{setDelay(0)}}, thus goes into the synchronized block and
> does a notifyAll
> * thread T1 continues in {{delay()}} after above mentioned check, thus now
> goes into the synchronized block - at this stage {{delay}} is {{0}} (as it's
> volatile) - thus it sets {{dt=0}}.
> * thread T1 then goes and calls {{wait(0)}} - which is an infinite wait,
> until it gets notified. This can be forever if the threshold is never ever
> hit again.
> Would suggest to do a {{while}} loop rather than a {{do-while}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
