commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] POOL-272: per-key numTestsPerEvictionRun
Date Wed, 03 Sep 2014 15:00:27 GMT
On 9/2/14 8:16 PM, Michael Berman wrote:
> Hi all,

Hi Michael,

Thanks for jumping in.  Welcome to Commons! 
> I'm contemplating POOL-272, which Phil Steitz said he was considering
> including in 2.3. The issue proposes introducing a per-key variant
> of numTestsPerEvictionRun for GenericKeyedObjectPool. The current behavior
> of the GenericKeyedObjectPool eviction loop is to try to iterate over idle
> objects under a particular key, numTests at a time, moving onto the next
> key only after every object has been hit or there's a conflict over a (no
> longer idle) object in the queue. However, since I'm configuring the pool
> size primarily per key (via minIdlePerKey, maxIdlePerKey, maxTotalPerKey),
> I would like to be able to make guarantees about the idle test frequency
> per key as well.
> I'm interested in soliciting opinions about how this new config property
> should interact with the existing one. Should it simply replace the global
> numTests property? Should both options be available, and the client chooses
> whether to configure it per key or globally? Or should both options be
> available, and the actual number of tests run is based on some combination
> of the two settings?

I think we should do the latter - add a new property and make test
execution dependent on the two, with a default for the new property
that keeps current behavior.  We would have to do anything other
than this in a major release and its always better to preserve
backward compatibility when you can.
> If the new property should replace the old one, how should the change be
> introduced? Can we just change the meaning of the old property? Or should
> we introduce the new property, and run the old one through a deprecation
> cycle? How do you normally handle API changes like this?
> If both options should exist, how should they interact? Keep the single
> property, and introduce a new boolean, numTestsAppliedPerKey, that switches
> between behaviors? If both options are available simultaneously, I'm having
> trouble coming up with a reasonable proposal for how they'd interact, but
> is there something that would make sense to others?

One way to do this would be to have the current property be a cap on
the total number of tests performed, but the new one basically
control the number done per key.  So if, e.g. numTestsPerEvictionRun
is 12, numEvictionTestsPerKey (or whatever we decide to call it) is
3,  the evictor does 3 tests for each key and then moves on to the
next immediately, up to 12.  I guess if there are fewer than
numEvictionTestsPerKey, the evictor just moves on.  If the evictor
gets all the way through before numTestsPerEcvictionRun it could
wrap around or just stop.  Would something like that work for you? 
Anyone have any better ideas?

> Thanks,
> Michael

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

View raw message