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) ? 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. Happy to participate to the refactoring :) 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 > >
