ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A Rahman (JIRA)" <ibatis-...@incubator.apache.org>
Subject [jira] Commented: (IBATIS-249) Race conditions in Throttle lead to thread blockage popping items from ThrottledPools under stress
Date Thu, 20 Mar 2008 06:08:24 GMT

    [ 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
> 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.

View raw message