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<phil.ste...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
