commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] 1.5-RC2 available for review
Date Tue, 02 Jun 2009 10:26:23 GMT
sebb wrote:
> On 02/06/2009, Phil Steitz <phil.steitz@gmail.com> wrote:
>   
>>     
>>>>  >
>>>>
>>>>
>>>> I just tried using the fixed numbers from a failed run (instead of
>>>>  using random ones), and it fails every time with the following
>>>>  settings:
>>>>
>>>>  runs=26
>>>>  Lengths=12,12,28
>>>>
>>>>  So it's clearly some kind of logic error - looks like it occurs where
>>>>  "runs" is an exact multiple of "totalInstances".
>>>>
>>>>
>>>>         
>>> s/multiple/divisor/
>>>
>>> As an experiment, I tried switching the order of the entries in the
>>> smallPrimes array to 3,2,5,7.
>>>
>>> I expected the test to fail on the second loop, but it did not fail.
>>>
>>> I think this must mean that pool.clear() does not reset the pool fully.
>>>
>>>
>>>
>>>       
>>  Bingo!  Clear was not fully clearing the pool.  Should be fixed now.
>>     
>
> The test with fixed values passed; I'm trying a soak test now.
>
>   
>> Thanks, sebb for hunting this down.
>>
>>     
>
> OK, NP.
>
> It's just lucky that my first test happened to hit the correct
> combination to cause the failure, otherwise we might not have noticed
> that there was a problem until much later.
>
> There probably needs to be a proper test for the clear() function.
>   
There is one in TestBaseKeyedObjectPool.   I have not been able to 
induce a failure there, but am working on it.
> BTW, I'm not sure that GOP.clear() is fully implemented - AFAICT it
> does not reset _allocationQueue, _evictionCursor, _numActive,
> _numInternalProcessing. There may be others.
>   
Yes.  That is next to fix.
> Likewise for GKOP.clear().
>   
I don't think we necessarily want to clear the allocation queue, 
numActive or numInternalProcessing on clear.  Its contract is just to 
clear the idle object queue.  The cursors should be reset, but clearing 
the underlying pools should do that.  Would probably do no harm to do 
this explicitly.
>   
>>  Phil
>>
>>     
>>>       
>>
>> ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>  For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message