commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Meir Shahar (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DBCP-260) borrowObject from the AbandonedObjectPool hangs on a wait() method when the WHEN_EXHAUSTED_BLOCK is set
Date Mon, 04 Feb 2008 08:27:08 GMT

    [ https://issues.apache.org/jira/browse/DBCP-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565286#action_12565286
] 

Meir Shahar commented on DBCP-260:
----------------------------------

Hi Phil,

 I use DBCP 1.2.2.

 You got it correctly and it is a corner condition, this would obviously not happen if a periodical
cleaner thread would remove idle connections. As far as I am concerned, the workaround is
fine. I submitted the bug to raise the issue and point at the location of the problem. If
you decide to keep things as they are, at least other users can be aware of this issue.

 Also, the third faq item on the wiki page (http://wiki.apache.org/jakarta-commons/DBCP) states
that the abandoned pool, though deprecated, is still active and will be supported in future
versions.

> 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
>         Environment: Windows XP, eclipse. JDK 1.6
>            Reporter: Meir Shahar
>            Priority: Minor
>
> 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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message