commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] "Smart" (aka auto-configure) pools
Date Fri, 05 Nov 2010 14:11:38 GMT
On 11/4/10 3:18 PM, Steve wrote:
> Not Paul, Phil. My bad!

Hey, NP.  I have a brother named Paul and he is way smarter than me :)
> S
> On Nov 4, 2010, at 2:34 PM, Steven Siebert <> wrote:
>> First, Paul, nice presentation at ApacheCon =)
>> I came up after the discussion to mention a feature I added to my
>> pool implementation, wanted to record this here and get community
>> thoughts.
>> What I have done for a customer (non-releasable, but I can
>> re-implement much cleaner) was essentially enable the pool to
>> "track" its maintenance operations over a 24-hour period (starting
>> at 0000) to better "predict" configuration changes that needed to
>> take place. This was helpful in our dev-to-production deployments
>> for configuration "burn-in"...we could have guessed what the
>> config for the pool should be...but this helped get it right
>> quickly. We kept it running (intentionally) and detected trends
>> over the first week. We then turned this feature off (via JMX) and
>> pool could then adjust itself based on it's learned data.
>> Admittedly, this was a "crude" implementation that was used to
>> improve performance due to our predictable spikes....there is a
>> lot more that could be done.
>> First question: is this coming the community would like?
>> Second: If it is desired, I implemented this by re-implementing
>> the evictor...Paul suggested this might also be a good fit for an
>> "outside" implementation (I can see this, as well)

We have talked a little over the years about making the pool smarter 
or in some sense "adaptive."  The crude capabilities available now 
via the maintenance thread (aka "Evictor") and idle instance 
settings could certainly be improved.  Have a look at the 
ErodingObjectPool and others in PoolUtils for other ideas in this 

The challenge with making a smart pool implementation is that it is 
hard to define an algorithm that "does no harm" (i.e. always 
actually improves performance) can be fully documented and is at 
least tractable to document, maintain and support.  That does not 
mean it is impossible and I am interested in having a look at your 

So we have something concrete to look at, why don't you create a 
patch with the new pool extending GOP if that is convenient?


>> Finally: What features would you like to see?
>> Thoughts?
>> Steve
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message