[
http://issues.apache.org/jira/browse/POOL-86?page=comments#action_12446150 ]
Mike Martin commented on POOL-86:
-
If you think through it, you'll realize that the lock ordering vulnerability
you're describing is not a function of there being an i
[
http://issues.apache.org/jira/browse/POOL-86?page=comments#action_12445951 ]
Mike Martin commented on POOL-86:
-
Sandy wrote:
> I think the changes you suggest to the evict method will fail to make forward
> progress if getNumTests() is less tha
[ http://issues.apache.org/jira/browse/POOL-86?page=all ]
Mike Martin updated POOL-86:
Attachment: pool-86.withtest.patch
I've attached another patch which includes the necessary changes to the unit
test.
> GenericKeyedObjectPool retaining too many idle ob
[ http://issues.apache.org/jira/browse/POOL-86?page=all ]
Mike Martin updated POOL-86:
Attachment: pool-86.patch
Here's a copy of the patch as applied against the current trunk sources.
> GenericKeyedObjectPool retaining too many idle objects
>
[
http://issues.apache.org/jira/browse/POOL-86?page=comments#action_12445665 ]
Mike Martin commented on POOL-86:
-
Sandy wrote:
> I think you have minimize and maximize backwards and reusing idle objects is
> why you'd want to use a pool. There ar
GenericKeyedObjectPool retaining too many idle objects
--
Key: POOL-86
URL: http://issues.apache.org/jira/browse/POOL-86
Project: Commons Pool
Issue Type: Bug
Affects Versions: 1.3
GenericKeyedObjectPool.getNumIdle() corrupted under high load
-
Key: POOL-85
URL: http://issues.apache.org/jira/browse/POOL-85
Project: Commons Pool
Issue Type: Bug
Affects Vers
