cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Avalon][C2] ComponentPool problems under Apache JMeter
Date Wed, 28 Feb 2001 20:58:31 GMT
Davanum Srinivas wrote:
> 
> Berin,
> 
> One major problem for the XSP scalability is that the Pool system is not good and we
keep creating
> new instances of the stuff that extends XSPGenerator. Avalon's ThreadSafePool and AbstractPool
> need to be re-visited/re-written. Here are the problems.
> 
> 1. AbstractPool's get() should allocate from a pool of available connections. I could
not
> understand why it has code that expands the pool? and that code never gets called because
m_pool
> is never null (init is called). Shouldn't the get() shrink the size of the available
pool if it is
> too big instead?

The pool code was based off of a composite of code that I wrote, Stefano wrote, and Federico
wrote.
Peter Donald did the current implementation.  He did some extensive testing and chose the
best performing
methodology.  Unfortunately it is not ThreadSafe, and was never intended to be (at least according
to
our last discussion on the subject).  That's why I suggested the ThreadSafe version to you.

> 2. Abstract Pool's put() should add the component to the available pool. So theoretically
if the
> pool size is not big enough it should expand the pool size not reduce it....

I agree.  The question is this: what kind of pooling policy do we want here?  There are several
policies
available:

Hard Resource Limiting: the pool will never expand, but will cause you to wait for an available
resource.
Soft Resource Limiting: the pool becomes a factory when the resources have been exausted--extra
resources
                        are destroyed when they return.
No Resource Limiting:   the pool expands to the extent necessary, but is never shrunk.

They all have performance/memory usage tradeoffs.

> 3. ThreadSafePool's get() and put() are declared final. They should not be.

I believe the ThreadSafePool was intended to be used standalone.

> 4. Currently the mechanism for growing and shrinking pools is severely broken. The code
has to be
> re-visited.

Ok.

> 5. Please note that C2's ComponentPool now uses ThreadSafePool and not AbstractPool directly.

yep.  Question, what do you think of the Pool used in the DataSources code.  There are some
things
that I need to do to it, but it is my code (Peter reformatted it).  There is a clear distinction
between used components and unused components.

> Can you please take a look?

Will do.  I am under the gun, but I can get to it sometime late next week. (unless I burn
the
midnight oil).

Peter, do you think you could help us out with the pool implementations?

Mime
View raw message