commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lee Breisacher <LBreisac...@seagullsoftware.com>
Subject RE: [pool] overly-aggressive locking on addObject()?
Date Wed, 09 May 2007 15:29:18 GMT
> 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:sandymac@gmail.com]
> 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 <LBreisacher@seagullsoftware.com> 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: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
> >
> >
>
>
> --
> Sandy McArthur
>
> "He who dares not offend cannot be honest."
> - Thomas Paine
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message