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