Note: This thread previously lived on the Commons User list.
On 9/11/06, Holger Hoffstaette <[EMAIL PROTECTED]> wrote:
On Sat, 09 Sep 2006 22:53:00 -0400, Sandy McArthur wrote: > I have been following this plan for pool: > http://wiki.apache.org/jakarta-commons/PoolRoadMap The current plan isn't > to require jdk 5 until Pool 3.0. OK. I don't agree but I guess that's my problem. ;-) However I think we can meet in the middle and make everyone happy, see below. > The code in svn for pool 2.0 implements the updated behavior but doesn't > have the performance characteristics I'm satisfied with on multi-cpu box. > (Current pool versions have the same performance bottle neck.) I got > stalled on reworking the code because of my wedding but I hope to start > moving forward again soon. Great, thanks for the update. I agree with all points on the roadmap for 2.0, especially the behavioral things like never having a null factory etc. Btw just curious how you test for lock contention etc.? I only know some JDK 1.5/1.6 features that measure the native locks and thread wait time but nothing for 1.4. I could provide test feedback on a shiny new dual-core Opteron.
I don't have any truly robust tests, just a series of micro-benchmarks that try to simulate single threaded and multi-threaded access patterns with fake-expensive poolable objects that I've run many times on a single cpu, a hyper threaded cpu, and a quad xeon cpu servers. My conclusion a few months ago was that the serialization that happens prevented the quad cpu server from delivering more than about 1.3 times the throughput of a single cpu server. I personally think it's reasonable to expect a quad cpu server should give you at least a 3 times performance boost over a single cpu server.
> While I have been working with Pool, there have been a number of people > who have submitted fast / non-blocking / unsynchronized pool > implementations but to achieve their speed they tend to ignore steps > needed to make a pool implementation thread-safe. There are many times > strict thread-safety isn't needed but I'm weary of including such code in > the official distribution. That sounds wrong - the whole idea behind lock-free/wait-free algorithms is that they are still thread-safe, yet with less unencessary synchronization and contention. If these contributions lead to a loss of thread safety for the pool they are just wrong, period. This stuff is hard and just removing synchronized statements because they work on someone's machine somewhere is a recipe for disaster.
Agreed, almost. If you don't need a pool with limits (maxActive/maxIdle/etc) and don't care if getNumIdle() or getNumActive are accurate then it is safe to strip away most all synchronization for pure speed. But thread-safe access to the backing idle object pool collection isn't the main bottleneck despite that most people seem to look their to make commons pool faster. What slows the provided pool implementations down is the state transitions poolable objects go through and the potential expense activating or passivating poolable objects while keeping the limits in check. For non-trivial poolable objects, which I assume all are, else you wouldn't be pooling them, the pool spends most of it's time in the activateObject, validateObject, and passivateObject methods. If those can run in parallel then the total throughput of the pool increases greatly, especially on multi-cpu servers. The problem is if you allow activate, validate, and passivateObject methods to run in parallel it gets much more complicated wether or not a poolable object that is transitioning state will cause a limit to be exceeded. For example pretty much every pool I've seen simply uses the internal Collection's .size() method as the result of getNumIdle(). But without full synchronization this isn't sufficient because a previously idle poolable object isn't really active until activateObject is done. A naive implementation will have a race condition that could allow too many database connections be created or whatever else is being pooled.
Anyway - since the roadmap for 2.0 indicates that JDK 1.4 is the target baseline it would IMHO be a wasted chance not to get best of both worlds - better data structures and readyness for JDK 1.5, yet run on JDK 1.4 to not cut off existing users. I therefore encourage you to consider the use of the backport concurrent library (http://dcl.mathcs.emory.edu/util/backport-util-concurrent/). It has a ASF-compatible license and some other Apache projects are adopting it too; the most recent example is MINA which had their own ThreadPool but *of course* struggled with the resulting and completely predictable bugs until last week. Using the backport would even enable the use of some highly cool stuff that is so far only in Mustang - mostly Deques which have significantly higher concurrency than single-lock Queues. Obviously producing a 'native' Tiger/Mustang version 3.0 from that will be trivial by simply fixing the package names.
I wasn't aware of backport-util-concurrent, I'll look into it.
If you want to discuss this further please send me email or let's move this to commons-dev. I would love to help with the development. My main project is with the Mule ESB (http://mule.codehaus.org/) and we make extensive use of both commons-pool and the backport library; having both work together would benefit everybody, especially since we're still based on JDK 1.4 as well (with a possible move to 1.5 in 2007). Please let me know what you think or even better when and how I can start committing.. :)
Patches attached to a issue can be submitted as soon as you have them ready, but you have to wait on a commiter to commit them. Then you have to be asked to become a committer, accept, and then it takes a some time and paper work to become official. You can read about it here: http://jakarta.apache.org/site/getinvolved.html -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
