commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] introducing Enumerations
Date Sun, 17 Oct 2010 16:33:09 GMT
On 10/17/10 8:37 AM, Benoit Perroud wrote:
> I would like to take the opportunity of this discussion around the action
> when the pool is exhausted to call for background reflexion about this 3
> behaviors :
> Is there really 3 behaviors ?
> For me GROW is useless, because in both case FAIL or BLOCK, the pool will
> GROW from initial size to the MAX size.
> I find dangerous to let the pool grow until it throws an OutOfMem.
> GROW can easily be "emulated" by a big MAX size (like Integer.MAX_VALUE) and
> a FAIL behavior once the max is reached.

Good question.  While I have never personally had occasion to 
configure it this way, I have over the years seen posts from users 
who did use GROW to implement an unlimited sized pool.  You are 
right that this could be done by just setting maxActive to a 
negative number (or a very large number).  The only rationale that I 
can see for holding on to this option is to support one of the 
following two implementation use cases, which are not strictly 
speaking relevant to the 1.x code:

a) an event is raised or a message is logged when maxActive is exceeded

b) a pool implementation interprets the maxActive setting as the 
largest expected pool size and uses this information somehow, while 
still supporting growth beyond maxActive

The second looks dubious, but the first might be useful.  Can anyone 
else see any other reason to keep this option?


> Kind regards,
> Benoit.
> 2010/10/12 Phil Steitz<>
>> On 10/12/10 7:23 AM, Mark Thomas wrote:
>>> On 12/10/2010 10:32, Simone Tripodi wrote:
>>>> Hi all,
>>>> following Phil's suggestion to point out candidates for deprecation /
>>>> removal, I notice that both GenericObjectPool and
>>>> GenericObjectPoolFactory share WHEN_EXHAUSTED_* properties of type
>>>> byte to discriminate the action to perform when the pool is exhausted.
>>>> Do you agree on replacing byte with enums? I mean, in therms of
>>>> design, IMHO is much more elegant having something like:
>>>> and at the same time provides to end users more clear API.
>>>> WDYT? just let me know, have a nice day,
>>> +1.
>>> In general, I am in favour of taking advantage of any and all Java 1.5
>>> features that lead to cleaner, safer, more readable code. I'm also in
>>> favour of removing as much unnecessary, unused, deprecated etc code as
>>> possible.
>>>   +1 here too.
>> Phil
>>   Mark
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message