On 9/14/10 6:17 AM, Benoit Perroud wrote:
Dear all,
Regarding
1) Replace wait/notify with 1.5+ thread management
Is there already any work or ideas on how to use Java util concurrent (JUC)
?
That is what I meant.
I did some tests with BlockingDeque as objects repository (Deque instead of
Queue to be able to achieve FIFO or LIFO behavior) and AtomicInteger as
counter, it works quite well.
But during my tests, I challenged the maxActive limit, and found more
convenient to have another quite different limit which is something like
"absolute max of objects in the pool" instead of maxActive. Using *Active
and *Idle counters can lead to objects already returned to the pool, but not
counted everywhere.
One thing we will want to talk about is whether or not to keep the
current semantics for object counting and tracking. That is part of
what I meant by item 4 below.
Happy to participate to the refactoring :)
Welcome!
Phil
Kind regards,
Benoit.
2010/9/13 Gary Gregory<ggreg...@seagullsoftware.com>
Yes, moving forward would be great. Foremost on my list is:
0) Generification (POOL-83)
All other items are fine with me but generics is #1.
"pool2."
That's fine by me, since removing (deprecated) methods breaks
compatibility.
Gary
-
Gary Gregory
Senior Software Engineer
Seagull Software
email: ggreg...@seagullsoftware.com
email: ggreg...@apache.org
www.seagullsoftware.com
-----Original Message-----
From: Phil Steitz [mailto:phil.ste...@gmail.com]
Sent: Sunday, September 12, 2010 11:14
To: Commons Developers List
Subject: [pool] Start work on 2.0?
I would like to begin working toward a version 2.0 of [pool]. I
would also like to declare the 1.x codebase as officially "bugfix
only." If others are OK with this and there is sufficient interest
in working toward a pool 2.0, I will cut a 1.x legacy branch and
start discussing / coding / applying patches for the following 2.0
features in trunk:
0) Generification (POOL-83)
1) Replace wait/notify with 1.5+ thread management
2) JMX instrumentation and management
3) Remove deprecated methods
4) Instance tracking (holding references to instances under
management and tracking events of interest from them - meeting DBCP
AbanonedObjectPool requirement)
5) Clean up and extend pool maintenance
Obviously, this is just my personal wish-list for [pool] and I am
open to any and all other ideas / itches. What I would really like
to know at this point is whether or not there is community interest
in a modernized version of [pool] containing features like the ones
listed above.
Ugly as it may be, I think that given the level of reuse of [pool],
if we do move forward with 2.0, we will have to change the package
name to "pool2." So I guess I am asking for consensus to make that
change in trunk as well.
Thanks in advance!
Phil
---------------------------------------------------------------------
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
