[
https://issues.apache.org/jira/browse/IBATIS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580678#action_12580678
]
A Rahman commented on IBATIS-249:
---------------------------------
Clinton, Thanks a lot for your quick reply. I will dig in my code. But here are
my results. Please let me know when the next release will be available for
download
When I test my application manually as a single user for more than an hour
continuously doing lots of retrieval, insert, update and deletes, I don't see
this problem, also I monitor the database at the same time no open connections
left.
I ran a simple load test with 5 concurrent users, doing simple retrieval of
records, the deadlock occurs and I also see some open connections waiting in
the database to be closed and application is dead.
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.
