commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (Commented) (JIRA)" <>
Subject [jira] [Commented] (POOL-212) GenericObjectPool allows maxIdle < minIdle
Date Thu, 12 Apr 2012 19:25:20 GMT


Mark Thomas commented on POOL-212:

This can't be fixed in the setters since in a number of scenarios (e.g. when used with DBCP
in Tomcat) there is no way to control the order in which the setters are called.
> GenericObjectPool allows maxIdle < minIdle
> ------------------------------------------
>                 Key: POOL-212
>                 URL:
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: Sergejs Melderis
>            Priority: Minor
> GenericObjectPool allows any values for minIdle and maxIdle, and performs no validation
on those values.
> It allows maxIdle to be less than minIdle, and that creates weird behavior during eviction.
> After each eviction the Evictor thread calls ensureMinIdle() method which adds objects
the pool using addObjectToPool() to make sure there at least minIdle objects in the pool.addObjectToPool()
on another hand makes sure that there no more then maxIdle objects in the pool, and immediately
destroys the newly created object.
> In my application we had minIdle configured to 100, but maxIdle wasn't configured and
 used the default value which is 8, and each eviction would create and destroy a bunch of
> This issue can be fixed by adding checks in setMinIdle and setMaxIdle, or by adding maxIdle
variable to the formula used in calculateDevicit() method.
> We use version 1.4, but I also tested it on latest 1.6 and observed the same behavior.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message