> If you feel you don't need all of that synchronization and > the pool will be correct enough without it then I suggest you > take the source to a pool implementation you like, copy it to > a private package and modify it.
Hi Sandy. I did as you suggested and it seems to work fine (although it would be much easier if GenericObjectPool was more subclassable, but that's a different issue). I still feel this is a bug in GenericObjectPool>addObject() and I would like to submit a JIRA with a patch. But I'm a little confused about 1.3 vs. 2.0 in SVN. Is the trunk the 2.0 sources or 1.3? I guess what I really need to know is which branch/tag/trunk I should start with so I have the latest sources for 1.x. Thanks, Lee > -----Original Message----- > From: Sandy McArthur [mailto:[EMAIL PROTECTED] > Sent: Friday, May 04, 2007 7:51 AM > To: Jakarta Commons Users List > Subject: Re: [pool] overly-aggressive locking on addObject()? > > Lee, > > The additional synchronization was needed for correct thread-safety. > Unfortunately it does make the pool a bit of a bottleneck as > your example demonstrates. > > If you feel you don't need all of that synchronization and > the pool will be correct enough without it then I suggest you > take the source to a pool implementation you like, copy it to > a private package and modify it. > > Someday I hope a much more concurrent pool is written but > that is hard thing to get right. Until then that is the best > I have for you. > > On 5/3/07, Lee Breisacher <[EMAIL PROTECTED]> wrote: > > I'm running into a performance problem and I think it can > be attributed to some overly aggressive locking in > GenericObjectPool>addObject(). Or perhaps I'm not using the > APIs just right, and someone can point out a better path for me. > > > > Here's the scenario: > > > > - I have a GenericObjectPool with a minIdle setting so it > always tries to keep a minimum number of objects in the pool. > > > > - My makeObject() method can sometimes take several seconds > to make a poolable object (yes, perhaps *that* is the cause > of my problems, but there's nothing I can do about it). > > > > - Sequence of events: > > 1. Thread A borrows an object that causes the pool to be > completely empty. > > > > 2. The ensureMinIdle() method (called from the Evictor > thread) calls addObject() which locks the pool and calls my > (long-running) makeObject(). > > > > 3. Thread B wants to borrow an object, but notices the pool > is empty so it waits (that's logic in my code). > > > > 4. Thread A finishes with its borrowed object and calls > returnObject(), but returnObject cannot enter because the > pool is locked from step 2 (which is still running in > makeObject()). So thread A is stuck waiting on the pool's lock. > > > > 5. Finally, makeObject() finishes and adds the newly made > object to the pool. > > > > 6. Thread A's returnObject now gets the lock and returns > the object to the pool. > > > > The performance problem is at step 4 -- there's an object > available for Thread B to use, but it cannot get a hold of it. > > > > Note that this was not a problem with commons-pool 1.2 - > several more "synchronized" were added to methods in version > 1.3. Perhaps those "synchronized" are necessary to prevent > other kinds of deadlock or race conditions, but perhaps the > locks are a bit too aggressive? In particular, it seems to me > that the call "out" to the client's makeObject() method in > addObject() should release the pool's lock. In fact, isn't it > always a bit risky to hold onto a lock during a call out to a > client method? > > > > Has anyone else run into this problem? Am I way off base in > my addObject() suggestion? > > > > Thanks, > > > > Lee > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > -- > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
