[ http://issues.apache.org/jira/browse/IBATIS-249?page=all ]
Sven Boden closed IBATIS-249:
-----------------------------
Fix Version: 2.2.0
Resolution: Fixed
Assign To: Sven Boden
Thanks for the IBATIS-249 patch Jonathan, changes checked in:
- Verified by at least 2 other people
- I played a little bit with it
- Logically the changes look correct
- No unit test case as it's difficult to simulate
> 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
> Assignee: Sven Boden
> Fix For: 2.2.0
> Attachments: IBATIS-249.diff
>
> 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
