[jira] Created: (POOL-130) GenericObjectPool.Evictor creates new objects although exactly minIdle objects are idle

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (POOL-130) GenericObjectPool.Evictor creates new objects although exactly minIdle objects are idle

Dmitri Blinov (Jira)
GenericObjectPool.Evictor creates new objects although exactly minIdle objects are idle
---------------------------------------------------------------------------------------

                 Key: POOL-130
                 URL: https://issues.apache.org/jira/browse/POOL-130
             Project: Commons Pool
          Issue Type: Bug
    Affects Versions: 1.4, 1.2
            Reporter: Torsten Feig


When you
- create a GenericObjectPool with these parameters: maxActive=100, maxIdle=100, minIdle=10, timeBetweenEvictionRunsMillis=360000 (1h), minEvictableIdleTimeMillis=30000 (5min)
- preload the 10 minIdle objects (10x borrowObject() + returnObject)
you have a pool with 10 idle objects.

Then every 1h the evictor destroys the 10 idle objects and creates 10 new ones. Why? After all, creating and tearing down pool objects is likely to be expensive. So why destroy the old objects when they exactly represent the minIdle objects? I don't see any need for this.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (POOL-130) GenericObjectPool.Evictor creates new objects although exactly minIdle objects are idle

Dmitri Blinov (Jira)

    [ https://issues.apache.org/jira/browse/POOL-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642997#action_12642997 ]

Sandy McArthur commented on POOL-130:
-------------------------------------

I'm not disagreeing with you that the idle object churn you describe is potentially wasted CPU cycles but unless poolable object creation is insanely expensive is this really that much wasted CPU time once an hour?

Also, a little bit of churn may have a net positive effect by breaking "strong" references so to allow the garbage collector to discard cached data that is tied to the poolable object via weak references and the like.

I'm not convinced this is a "problem" needing a fix though a good patch of a better behavior could change my mind.

> GenericObjectPool.Evictor creates new objects although exactly minIdle objects are idle
> ---------------------------------------------------------------------------------------
>
>                 Key: POOL-130
>                 URL: https://issues.apache.org/jira/browse/POOL-130
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 1.2, 1.4
>            Reporter: Torsten Feig
>
> When you
> - create a GenericObjectPool with these parameters: maxActive=100, maxIdle=100, minIdle=10, timeBetweenEvictionRunsMillis=360000 (1h), minEvictableIdleTimeMillis=30000 (5min)
> - preload the 10 minIdle objects (10x borrowObject() + returnObject)
> you have a pool with 10 idle objects.
> Then every 1h the evictor destroys the 10 idle objects and creates 10 new ones. Why? After all, creating and tearing down pool objects is likely to be expensive. So why destroy the old objects when they exactly represent the minIdle objects? I don't see any need for this.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (POOL-130) GenericObjectPool.Evictor creates new objects although exactly minIdle objects are idle

Dmitri Blinov (Jira)
In reply to this post by Dmitri Blinov (Jira)

    [ https://issues.apache.org/jira/browse/POOL-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643467#action_12643467 ]

Torsten Feig commented on POOL-130:
-----------------------------------

In my case, the creation is probably not very expensive, but the outcome is ugly anyway: we use GenericObjectPool as a thread pool. Every object created is a thread with a unique name (basename + incremented counter) so to tell them apart (in logs or threaddumps). We'd like to have 10 minIdle threads for a quick response to average workload. When the application runs a while (i.e. for days), there may however be no work for these threads at all. So the operations department frowns when looking into the logs and seeing ridiculously high thread counters.

I haven't looked into the source code and can therefor not provide a patch. But it appears to me that it should be quite simple as this "churn" of idle objects seems to be an additional functionality - just cut out the code that destroys und recreates idle objects.

> GenericObjectPool.Evictor creates new objects although exactly minIdle objects are idle
> ---------------------------------------------------------------------------------------
>
>                 Key: POOL-130
>                 URL: https://issues.apache.org/jira/browse/POOL-130
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 1.2, 1.4
>            Reporter: Torsten Feig
>
> When you
> - create a GenericObjectPool with these parameters: maxActive=100, maxIdle=100, minIdle=10, timeBetweenEvictionRunsMillis=360000 (1h), minEvictableIdleTimeMillis=30000 (5min)
> - preload the 10 minIdle objects (10x borrowObject() + returnObject)
> you have a pool with 10 idle objects.
> Then every 1h the evictor destroys the 10 idle objects and creates 10 new ones. Why? After all, creating and tearing down pool objects is likely to be expensive. So why destroy the old objects when they exactly represent the minIdle objects? I don't see any need for this.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Closed: (POOL-130) GenericObjectPool.Evictor creates new objects although exactly minIdle objects are idle

Dmitri Blinov (Jira)
In reply to this post by Dmitri Blinov (Jira)

     [ https://issues.apache.org/jira/browse/POOL-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Phil Steitz closed POOL-130.
----------------------------

    Resolution: Invalid

The behavior described is as designed and consistent with the documentation.  When you set minEvictableIdleTimeMillis=30000 (5min), you are telling the pool that you do not want instances to sit idle in the pool for more than 5 min.  That means that when the evictor runs (once an hour according to your config) it is going to destroy instances that have been idle more than 5 minutes.  The minIdle setting says you want to ensure there are 10 idle instances in the pool, so the pool is behaving as designed when it destroys what it sees as "stale" instances and replaces them with new ones to ensure minIdle is met.  If you want to suggest a change in the API to support different behavior, start by posting a suggestion to [hidden email].

> GenericObjectPool.Evictor creates new objects although exactly minIdle objects are idle
> ---------------------------------------------------------------------------------------
>
>                 Key: POOL-130
>                 URL: https://issues.apache.org/jira/browse/POOL-130
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 1.2, 1.4
>            Reporter: Torsten Feig
>
> When you
> - create a GenericObjectPool with these parameters: maxActive=100, maxIdle=100, minIdle=10, timeBetweenEvictionRunsMillis=360000 (1h), minEvictableIdleTimeMillis=30000 (5min)
> - preload the 10 minIdle objects (10x borrowObject() + returnObject)
> you have a pool with 10 idle objects.
> Then every 1h the evictor destroys the 10 idle objects and creates 10 new ones. Why? After all, creating and tearing down pool objects is likely to be expensive. So why destroy the old objects when they exactly represent the minIdle objects? I don't see any need for this.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.