commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] how to put a hard limit on idle time?
Date Sat, 29 Jan 2011 00:18:42 GMT
On Fri, Jan 28, 2011 at 6:47 PM, Alan Krueger <> wrote:
> My development team is trying to leverage the commons-pool GenericObjectPool
> with objects that have a hard upper-limit of 5 seconds of idle time on them.
>  We have the pool configured to try to evict objects like this before
> they're borrowed, but under load the eviction thread doesn't appear able to
> guarantee that this occurs.
> Would it make sense to either add a setting that sets a maximum idle time
> that's checked on borrow, or perhaps expose the idle time (or pooled object
> timestamp) to the PoolableObjectFactory?
> Any suggestions?
Good question.  If you don't mind, it would be great to open a JIRA
capturing this enhancement request, which as you have determined, is
not really supported directly by [pool] today.

I assume it is OK for the "stale" objects to sit in the pool and get
destroyed only when you attempt to borrow them.  Correct?

I don't see a clean way to expose the internal timestamp to the
factory.  I understand your motivation there, but it kind of breaks
the API in a basic way and would require a lot of changes to
implement.  We can talk about other ways to satisfy the enhancement
request on the dev list.

The simplest solution which you have probably thought of is to just
manage your own timestamps - i.e., add a timestamp to the objects
created by your factory, set in makeObject, and have your factory's
validate method check the timestamp.  Then set testOnBorrow to true
and the factory's validate method can check for staleness. Then you
can turn off the evictor altogether, which in addition to not being
able to keep up with your eviction needs will also hurt performance if
run at very high frequency under load.

The requirement to only hold instances for 5 seconds is a pretty
severe limitation that will limit the value of the pool.  If there is
any way to engineer the instances so that they can tolerate longer
inactivity periods, you will get more value from the pool.


> Thanks,
> Alan Krueger
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message