I was proposing having both properties be maxes, not mins; whichever we hit first is the limit. I agree that not having a cap on the total number of tests performed is dangerous (I wouldn't really set it to max int; just something pretty high). However, there is some precedent for unbounded tests: currently, if you set the limit to a negative, the number of tests scales with the number of values. This doesn't seem fundamentally more dangerous than scaling with the number of keys.
In some situations, though, it's true that it's important to be able to cap the total number of tests. By the same logic, I may also not want an unbounded number of tests to be able to occur for each key, which makes the "there will always be numTests performed regardless of the perKey setting" option sound scary. Maybe there should be another switch for whether we want the min or the max? On Fri, Sep 5, 2014 at 11:28 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 9/3/14 8:53 AM, Michael Berman wrote: > > Thanks for the feedback Phil! > > > > > >> 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? > > > > "No more than numEvictionTestsPerKey per key and no more than > > numTestsPerEvictionRun total" would definitely address my use case (in my > > case, I'll just set numTestsPerEvictionRun to Int.MAX or something), but > I > > do wonder if that's what everyone would want. I could imagine expecting > the > > behavior to be "At least numEvictionTestsPerKey per key and at least > > numTestsPerEvictionRun total" (which would be the behavior if we wrapped > > around instead of just stopping). I suppose it's easy to make it clear > > which behavior we have in documentation, but that presumes the one I want > > is likely to be universally more useful than the alternative. Think I can > > make that assumption? > We would have to rename numTestsPerEvictionRun if we were to change > it to mean a min. I would personally not like that. I would rather > leave it defined as is and just have the new property control when > the evictor moves from key to key. Another option would be to have > the new property override the old one - so if numEvictionTestsPerKey > is set (i.e. not the default), then numTestsPerEvictionRun is > ignored and the evictor is controlled completely by the second one. > > Personally, I would favor the first of my suggestions above - > numTestsPerEvictionRun determines the total number of tests > performed and numEvictionTestsPerKey determines how many tests are > done in each key set before moving to the next key. Not having a > cap on the total number of tests performed is dangerous, as there is > no bound to the number of keys so just doing numEvictionTestsPerKey > for every key each evictor run could result in very long-running > evictors. > > It would be good to get some other opinions on this. Anyone have > ideas / preferences? > > Phil > > > > > > With respect to naming: > > numEvictionTestsPerKey is definitely more concise and readable than > > numTestsPerEvictionRunPerKey, but I wonder if it makes it less obvious > that > > it's tightly connected to numTestsPerEvictionRun. In code completion, the > > setters wouldn't appear next to each other, which might hurt > > discoverability. Maybe just referencing each other in docs is enough to > > mitigate that. Any votes one way or the other? > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
