You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simone Tripodi <si...@gmail.com> on 2010/10/12 11:32:29 UTC
[pool] introducing Enumerations
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:
enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
and at the same time provides to end users more clear API.
WDYT? just let me know, have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] introducing Enumerations
Posted by Simone Tripodi <si...@gmail.com>.
Hi James,
thanks for the feedback!!!!
Guys, please review r1021756, I introduced a WhenExhaustedAction
enumeration that's shared between all
Generic(Keyed)?ObjectPool(Factory)? components.
I also removed the useless
TestGenericObjectPool.testInvalidWhenExhaustedAction() since
WhenExhaustedAction is already value-safety
Does it work for you? Please let me know!
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 1:40 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> +1 to enums
>
> On Tue, Oct 12, 2010 at 7:34 AM, Simone Tripodi
> <si...@gmail.com> wrote:
>> Hi Mark,
>> thank a lot for your feedback! I agree with your POV, since we're
>> using Java1.5 we should take advantage of the whole provided features
>> :)
>> Thanks!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Oct 12, 2010 at 1:23 PM, Mark Thomas <ma...@apache.org> 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:
>>>>
>>>> enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
>>>>
>>>> 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.
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] introducing Enumerations
Posted by James Carman <ja...@carmanconsulting.com>.
+1 to enums
On Tue, Oct 12, 2010 at 7:34 AM, Simone Tripodi
<si...@gmail.com> wrote:
> Hi Mark,
> thank a lot for your feedback! I agree with your POV, since we're
> using Java1.5 we should take advantage of the whole provided features
> :)
> Thanks!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Oct 12, 2010 at 1:23 PM, Mark Thomas <ma...@apache.org> 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:
>>>
>>> enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
>>>
>>> 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.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> 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
Re: [pool] introducing Enumerations
Posted by Simone Tripodi <si...@gmail.com>.
Hi Mark,
thank a lot for your feedback! I agree with your POV, since we're
using Java1.5 we should take advantage of the whole provided features
:)
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 1:23 PM, Mark Thomas <ma...@apache.org> 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:
>>
>> enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
>>
>> 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.
>
> Mark
>
> ---------------------------------------------------------------------
> 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
Re: [pool] introducing Enumerations
Posted by Benoit Perroud <ki...@gmail.com>.
This behavior can also be achieved using the maxIdle parameter :
maxActive : -1 or Integer.MAX
maxIdle : 200 for example
we can thus borrow more than 200 objects, and the 201st will be discarded
once returned to the pool.
So now again, couldn't we achieve the same behavior with only FAIL and BLOCK
?
Kind regards,
Benoit.
2010/10/17 James Carman <ja...@carmanconsulting.com>
> On Sun, Oct 17, 2010 at 1:20 PM, Phil Steitz <ph...@gmail.com>
> wrote:
> >
> > Yes, but the question is do you really *need* this option, since setting
> > maxActive = -1 effectively accomplishes the same thing.
> >
>
> Not exactly. The distinction between the two approaches would be more
> obvious at return object time. With maxActive set to -1 or
> Integer.MAX_VALUE, the maxActive restriction is never reached. With
> the "grow" strategy (and a reasonable maxActive), the maxActive limit
> can be checked on return and the object can be discarded rather than
> returned to the pool if the pool has been "grown" beyond its maximum
> allowable limit. Essentially, "grow" turns maxActive into a guideline
> rather than a rule. With maxActive turned off, your pool can grow
> unbounded. Of course, maxIdle also comes into play, but you could
> have that turned off too (then you're simply using maxActive to manage
> your pool size).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [pool] introducing Enumerations
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Oct 17, 2010 at 1:20 PM, Phil Steitz <ph...@gmail.com> wrote:
>
> Yes, but the question is do you really *need* this option, since setting
> maxActive = -1 effectively accomplishes the same thing.
>
Not exactly. The distinction between the two approaches would be more
obvious at return object time. With maxActive set to -1 or
Integer.MAX_VALUE, the maxActive restriction is never reached. With
the "grow" strategy (and a reasonable maxActive), the maxActive limit
can be checked on return and the object can be discarded rather than
returned to the pool if the pool has been "grown" beyond its maximum
allowable limit. Essentially, "grow" turns maxActive into a guideline
rather than a rule. With maxActive turned off, your pool can grow
unbounded. Of course, maxIdle also comes into play, but you could
have that turned off too (then you're simply using maxActive to manage
your pool size).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] introducing Enumerations
Posted by Phil Steitz <ph...@gmail.com>.
On 10/17/10 12:38 PM, James Carman wrote:
> On Sun, Oct 17, 2010 at 12:38 PM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> From the Javadocs for GenericObjectPool:
>>
>> "when the pool is exhausted (i.e., the maximum number of active
>> objects has been reached), the borrowObject() method should simply
>> create a new object anyway. "
>>
>> So, it's a different case. It allows for you to disregard the maximum size.
>>
>
> Sorry, this is the description of the WHEN_EXHAUSTED_GROW option.
Yes, but the question is do you really *need* this option, since
setting maxActive = -1 effectively accomplishes the same thing.
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
Re: [pool] introducing Enumerations
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Oct 17, 2010 at 12:38 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> From the Javadocs for GenericObjectPool:
>
> "when the pool is exhausted (i.e., the maximum number of active
> objects has been reached), the borrowObject() method should simply
> create a new object anyway. "
>
> So, it's a different case. It allows for you to disregard the maximum size.
>
Sorry, this is the description of the WHEN_EXHAUSTED_GROW option.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] introducing Enumerations
Posted by James Carman <ja...@carmanconsulting.com>.
>From the Javadocs for GenericObjectPool:
"when the pool is exhausted (i.e., the maximum number of active
objects has been reached), the borrowObject() method should simply
create a new object anyway. "
So, it's a different case. It allows for you to disregard the maximum size.
On Sun, Oct 17, 2010 at 8:37 AM, Benoit Perroud <ki...@gmail.com> 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.
>
> Kind regards,
>
> Benoit.
>
>
>
> 2010/10/12 Phil Steitz <ph...@gmail.com>
>
>> 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:
>>>>
>>>> enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
>>>>
>>>> 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: 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
Re: [pool] introducing Enumerations
Posted by Phil Steitz <ph...@gmail.com>.
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?
Phil
>
> Kind regards,
>
> Benoit.
>
>
>
> 2010/10/12 Phil Steitz<ph...@gmail.com>
>
>> 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:
>>>>
>>>> enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
>>>>
>>>> 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: 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
Re: [pool] introducing Enumerations
Posted by Benoit Perroud <ki...@gmail.com>.
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.
Kind regards,
Benoit.
2010/10/12 Phil Steitz <ph...@gmail.com>
> 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:
>>>
>>> enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
>>>
>>> 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: 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
>
>
Re: [pool] introducing Enumerations
Posted by Phil Steitz <ph...@gmail.com>.
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:
>>
>> enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
>>
>> 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: 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
Re: [pool] introducing Enumerations
Posted by Mark Thomas <ma...@apache.org>.
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:
>
> enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
>
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org