[OAK-4532] race-condition in commit-rate-limiter

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.5.4
• Fix Version/s: 1.5.6, 1.6.0
• Component/s: core
• Epic Link: Improve observation resilience
• Assignee: Stefan Egli
• Reporter: Stefan Egli
• Created: 04/Jul/16 15:42
• Updated: 10/Nov/16 09:51
• Resolved: 07/Jul/16 15:32

Description

CommitRateLimiter.delay 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