On Fri, Jan 28, 2011 at 7:18 PM, Phil Steitz <[email protected]> wrote: > 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,
Sorry, activateObject will also have to reset the timestamp. 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]
