[
https://issues.apache.org/jira/browse/POOL-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565189#action_12565189
]
Phil Steitz commented on POOL-123:
----------------------------------
What version of DBCP are you running?
IIUC, this is really an enhancement request for AbandonedObjectPool, which is
a (deprecated) DBCP class.
Pool handles the notification correctly, but again assuming I understand the
use case correctly, AbandonedObjectPool's removeAbandoned method will not get
called unless and until another thread arrives to invoke borrowObject. This is
a corner case for AbandonedObjectPool, which I think is best handled by the
client by setting maxWait.
> borrowObject from the GenericObjectPool hangs on a wait() method when the
> WHEN_EXHAUSTED_BLOCK is set
> -----------------------------------------------------------------------------------------------------
>
> Key: POOL-123
> URL: https://issues.apache.org/jira/browse/POOL-123
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.4
> 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.
