[ http://issues.apache.org/jira/browse/IBATIS-249?page=all ]
Jonathan Burstein updated IBATIS-249: ------------------------------------- Attachment: IBATIS-249.diff Attaching patch > 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 > 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