You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Phil Steitz (JIRA)" <ji...@apache.org> on 2011/04/30 20:44:03 UTC

[jira] [Updated] (DBCP-260) borrowObject from the AbandonedObjectPool hangs on a wait() method when the WHEN_EXHAUSTED_BLOCK is set

     [ https://issues.apache.org/jira/browse/DBCP-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Phil Steitz updated DBCP-260:
-----------------------------

    Affects Version/s: 1.3
                       1.4

> borrowObject from the AbandonedObjectPool hangs on a wait() method when the WHEN_EXHAUSTED_BLOCK is set
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DBCP-260
>                 URL: https://issues.apache.org/jira/browse/DBCP-260
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 1.2, 1.2.1, 1.2.2, 1.3, 1.4
>         Environment: Windows XP, eclipse. JDK 1.6
>            Reporter: Meir Shahar
>            Priority: Minor
>             Fix For: 2.0
>
>
> This bug is related to bugs #1, #38 & #102. Thought the bugs are closed, I think there is a (edge condition) scenario that is not handled properly:
> Config:
> 10 active connections limit
> RemoveAbandoned set to 'on'
> RemoveAbandonedTimeout set to x (say 60 secs)
> Suppose 10 connections were borrowed and the 11 th request was issued, all within a time frame shorted then the timeout.
> The first 10 requests are in methods that do not properly release the connection.
> This means that the 11 th thread is waiting indefinitely until a notify is sent.
> The 'non releasing' threads the first 10 connections hence no notification is sent
> The 'garbage collection' is performed by the calling AbandonedObjectPool before calling the GenericObjectPool.borrowObject(...). This garbage collection will not be called again and the wait() will stay locked though some connections might be come available through timeout expiration.
> The quick n dirty workaround is to setMaxWait(...) but still I think a better solution will be along the lines of:
> 1. Waiting for removeAbandonedTimeout secs
> 2. Retry regular allocation

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira