commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [POOL] Offer of help for a 1.4 release
Date Sat, 05 Jan 2008 22:15:25 GMT
On Jan 5, 2008 7:49 AM,  <kutzi@gmx.de> wrote:
> Hi Phil,
>
> thanks for taking my issue serious.
>
> Phil Steitz wrote:
>
> > Thanks again for the feedback.   Any other opinions / suggestions on
> > this are appreciated.  I suggest the following compromise, which would
> > also fix the maxActive exceeded by one issue I discovered with
> > 1.2/1.4-RC1 yesterday:
> >
> > (*) Move makeObject back inside synchronized scope in borrowObject.
> > (patch below)
> >
> > This addresses Christoph's production use case (assuming I have
> > understood it correctly) and also closes the maxActive exceeded by one
> > problem that my testing uncovered yesterday.  It does not have a huge
> > performance impact in the tests that I have run and still leaves
> > activation and validation (the per-request operations) outside of
> > synchronized scope.  More elegant solutions to both problems are
> > certainly possible and we can consider them in subsequent releases -
> > including configurable serialization of just the makes.
>
> This is not what I was trying to achieve :-(
> While this fixes my issue with the parallel creation of objects, it
> reopens another issue which I have with the implementation in pool 1.3:
>
> The pool blocks completely while an object creation is in progress.
> Just consider the following use case:
>
> - Thread A tries to borrow an object. The pool contains no idle objects,
> hence a new one is created
> - While object is still in creation, Thread B tries to return his
> borrowed object to the pool. Since returning the object depends on the
> same synchronization lock as makeObject, B will block as long as the new
> object isn't created (which can maybe take several seconds, as seen in
> my use case). I think this is unacceptable.

Agreed.  This is why the synchronization was removed.  Bad idea to
stay with the 1.3 setup.

> - Still while the creation is in progress, Thread C wants to borrow an
> object. It cannot continue, either, though an idle object would be
> available, if B could have returned its object
>
> I propose, as in my previous post, a distinct lock for object creation.
> I have attached a patch which should fix this behavior, but probably
> will not fix the "maxActive exceeded by 1". Do you already have a
> testcase for this one?

I am working on this now.  I don't have a unit test yet.  I discovered
the problem using load tests generated using the performance module in
commons-sandbox.  The dummy factory that the pool tests use keeps
track of (makes - destroys) and throws IllegalStateException if this
quantity exceeds maxActive for the pool. I was able to get this to
happen using the config I posted on the other thread.

>The existing unit tests run without errors when
> my patch is applied.
>
Thanks!  Testing now.
>

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


Mime
View raw message