Race conditions in Throttle lead to thread blockage popping items from
ThrottledPools under stress
--------------------------------------------------------------------------------------------------
Key: IBATIS-249
URL: http://issues.apache.org/jira/browse/IBATIS-249
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.7
Reporter: Jonathan Burstein
com.ibatis.common.util.Throttle.increment contains a synchronization error.
Currently, when a waiting thread returns from LOCK.wait it will increment count
and return without checking that count is below limit. There are a number of
situations where LOCK.wait can complete but the count will not be less than the
limit:
1) The wait was interrupted
2) There was a spurious thread wakeup
3) Another thread obtained the lock between the time LOCK.notify was called (by
a thread calling decrement) and the wait returned.
The fix here is to re-check the value of count after exiting the wait (using a
while loop). A small amount of extra logic is necessary to satisfy maxWait
properly.
ThrottledPool.pop attempts to work around these race conditions by catching
swallowing all exceptions from throttle.increment and pool.remove(0) and
looping until an item is obtained. Since the increment call is within the loop
this logic can lead to multiple increments with no corresponding decrements.
Note that an IndexOutOfBound exception from pool.remove(0) is an artifact of
the bug in Throttle.increment -- this could never occur if Throttle behaved
correctly.
This routine should simple call throttle.increment and pool.remove(0). It
should most certainly not swallow exceptions.
Finally, ThrottledPool.push incorrectly calls throttle.decrement if the
parameter is invalid (null or of an incorrect type).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
