[
https://issues.apache.org/jira/browse/IBATIS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580720#action_12580720
]
A Rahman commented on IBATIS-249:
---------------------------------
I took the latest code from SVN which has no Throttle, tested. It works GREAT,
no deadlocks. THANK YOU CLINTON! By the way iBATIS is an excellent tool, THANK
YOU!
I was in a big trouble with my application in production giving this deadlock
problem, its resolved, i will have a peacefull sleep.....
Abdur Rahman
> Race conditions in Throttle lead to thread blockage popping items from
> ThrottledPools under stress
> --------------------------------------------------------------------------------------------------
>
> Key: IBATIS-249
> URL: https://issues.apache.org/jira/browse/IBATIS-249
> Project: iBatis for Java
> Issue Type: Bug
> Components: SQL Maps
> Affects 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.
-
You can reply to this email to add a comment to the issue online.
