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? Phil > > Thanks, > Michael > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
