Hi all,
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?

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?

Thanks,
Michael

Reply via email to