On 9/15/14 9:02 AM, Michael Berman wrote:
> I'm fine with pushing it off to 2.4, since it doesn't seem like we're
> converging on an obviously preferred implementation.
>
> That said, I'm not too worried about maintaining the per-key iterator, even
> though the key list is dynamic. The eviction pro
I'm fine with pushing it off to 2.4, since it doesn't seem like we're
converging on an obviously preferred implementation.
That said, I'm not too worried about maintaining the per-key iterator, even
though the key list is dynamic. The eviction process already maintains its
own list of keys, which
On 9/11/14 11:39 AM, Phil Steitz wrote:
> On 9/11/14 8:55 AM, Phil Steitz wrote:
>> On 9/9/14 11:38 AM, Michael Berman wrote:
>>> Great, thanks! I have all the new config property boilerplate in place and
>>> I understand how it should work, but I'm debating the best way to implement
>>> the per-ke
On 9/11/14 8:55 AM, Phil Steitz wrote:
> On 9/9/14 11:38 AM, Michael Berman wrote:
>> Great, thanks! I have all the new config property boilerplate in place and
>> I understand how it should work, but I'm debating the best way to implement
>> the per-key queues. It would be nice if the test iterati
On 9/9/14 11:38 AM, Michael Berman wrote:
> Great, thanks! I have all the new config property boilerplate in place and
> I understand how it should work, but I'm debating the best way to implement
> the per-key queues. It would be nice if the test iteration for each key
> resumed in the same place
Great, thanks! I have all the new config property boilerplate in place and
I understand how it should work, but I'm debating the best way to implement
the per-key queues. It would be nice if the test iteration for each key
resumed in the same place the next time the cycle hits that key, but this
im
On 9/5/14 8:44 AM, Michael Berman wrote:
> I was proposing having both properties be maxes, not mins; whichever we hit
> first is the limit.
Sorry, I misunderstood. That sounds fine to me. I would be happy
to work with you on a patch implementing this. If you want to take
a stab at it, just att
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:
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, nu
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 ca
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 GenericKeyedObje
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
obje
12 matches
Mail list logo
