On Fri, Jan 28, 2011 at 6:47 PM, Alan Krueger <[email protected]> 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. Phil > Thanks, > Alan Krueger > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
