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 Fri, 04 Jan 2008 02:09:04 GMT
On Jan 3, 2008 12:40 PM, Mark Thomas <markt@apache.org> wrote:
> Christoph Kutzinski wrote:
> > - creating a new object means the pool is exhausted which in turn usually means
that we have a high-load situation.
> > - creation of new objects is expensive (probably even more in high-load situations).
This is why we originally used the pool
> > - so in conclusion it is probably a bad idea to create multiple object in parallel
>
> I don't see how serializing object creation can help performance. If you
> have a test case and some numbers that show otherwise, I would be very
> interested in taking a look.
>
> If you are really worried about the cost of object creation then you can
> configure the pool to create all the objects at start-up and block until a
> free object is available.
>

Thanks for the feedback, Christoph; but I agree with Mark.  I suspect
most pool users keep the default whenExhaustedAction, which is to
block.  That means that objects get created a) on demand, when there
are no idle instances, but maxActive has not been reached b) when
addObject is invoked to prefill or augment the idle object pool
explicitly or c) when minIdle is set and the idle object evictor runs.
 Even when a) happens during a load spike, it is better to do the
makes in parallel, especially if there is some latency involved and
there are resources available to process the makes in parallel (which
will be the case in, e.g. a database connection pool). This is all
assuming that there is good synchronized control over the number of
makes.  (See post to follow.).  As Mark said, if makes are *very*
expensive, you can prefill and then configure the pool to block.

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

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


Mime
View raw message