Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of
 LBreisacher@seagullsoftware.com designates 12.6.96.2 as permitted sender)
From: Lee Breisacher <LBreisacher@seagullsoftware.com>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>,
	"Sandy@McArthur.org" <Sandy@McArthur.org>
Date: Wed, 9 May 2007 11:29:18 -0400
Subject: RE: [pool] overly-aggressive locking on addObject()?
Thread-Topic: [pool] overly-aggressive locking on addObject()?
Thread-Index: AceOW6h3Pep9NdbJS3SHsUa+brthLQD8dKDg
Message-ID: <C8B84F0CE259774E8CA549BA7FFAE9481490B353E5@E2K7MB.seagull.nl>
References: <C8B84F0CE259774E8CA549BA7FFAE948021B2FD3BA@E2K7MB.seagull.nl>
 <6bde122b0705040750o36b73156s58d6c02860dba50b@mail.gmail.com>
In-Reply-To: <6bde122b0705040750o36b73156s58d6c02860dba50b@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> 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 wou=
ld 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 lik=
e 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 t=
o know is which branch/tag/trunk I should start with so I have the latest s=
ources 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