You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2016/07/04 15:43:11 UTC
[jira] [Created] (OAK-4532) race-condition in commit-rate-limiter
Stefan Egli created OAK-4532:
--------------------------------
Summary: 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
[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)