[
https://issues.apache.org/jira/browse/POOL-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010174#comment-13010174
]
Mark Thomas commented on POOL-180:
----------------------------------
I think Phil's analysis is correct but the test fails due to a mis-match
between WaiterFactory and the pool.
WaiterFactory#maxActive=5 <=> pool#maxTotal =8
WaiterFactory#maxActivePerKey=8 <=> pool#maxActive=5
There are four keys in the test. The pool could have 3 keys each with 2 objects
for a total of 6 objects. 6 < 8 (pool#maxTotal) and 2 < 5 (pool#maxActive) so
the pool is well within limits. However, 6 !< 5 hence the WaiterFactory throws
an error.
With the mismatch corrected, I can't recreate the error but I will fix the
issue Phil identified.
> Max active per key can be exceeded by one
> -----------------------------------------
>
> Key: POOL-180
> URL: https://issues.apache.org/jira/browse/POOL-180
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.5, 1.5.4
> Reporter: Phil Steitz
> Priority: Minor
> Fix For: 1.5.6
>
> Attachments: maxAcitivePerKeyExceededTest.patch
>
>
> When instances in the pool fail validation with high frequency, maxTotal is
> less than maxActive times the number of keys, and destroy has latency, the
> maxActive contract can be violated (i.e., the number of instances created
> under a given key minus the number destroyed can exceed maxActive).
> Attaching a test case that fails against POOL_1_X
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
