avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: component and MT
Date Wed, 30 May 2001 03:30:23 GMT
Sky Torch wrote:
> Hello,
> are components in avalon supposed to be multi-thread safe? it seems that
> it's using single-thread model. if so, how to improve through-put of the
> system - i understand there's a pool impl, how to enable a component pool,
> is it a big memory consumption, what's cons and pros of doing this, etc. ?

1) It is not always possible to be ThreadSafe--but it is preferred. 
that way
   You only have to have one instance of the component.

2) Improving through-put of the system:

Excalibur's ComponentManager assumes that unless otherwise specified we
dealing with SingleThreaded components.  That means that a new component
instance is created for every lookup.  This is not always desirable
it puts allot of stress on the garbage collector.

For that reason, if a Component cannot be ThreadSafe, then it is
for it to be Poolable.  Please note that those three different
are interfaces that a Component can implement.

A new instance is created for every lookup.  It is the default because
is the safest assumption.  However it should only be implemented if the
component is not reentrant (i.e. only useable one time).

One instance is created and shared to all Components who look it up.  It
can only be used if the interface and the component is truly
That means the code is reentrant, and no state is maintained between
method calls.

A set number of instances are created and passed to components that look
it up.  It should be used when code cannot be threadsafe due to
state between method calls but the component is reentrant.  The set
of available components reduces the strain on the garbage collector,
increasing the overall load capacity and throughput of your system.

The same as Poolable, but there is an extra method that is called to
the Component back to the original state.

3) How to enable a component pool:
implement the Poolable or Recyclable interfaces and use the Excalibur
Component manager.

4) Is it a big memory consumption?  It depends on the size and
of your component.  The default pool implementation starts with 4
and as demand requires it will grow to 16 instances.  If demand exceeds
the pool implementation will create new instances, but destroy them when
they are released.  It is a soft resource limit--this guarantees success
of the call, and manages memory consumption.  Truth be told, it is
on a Java system to keep components ready in a pool than it is to create
and destroy them on every request.  It reduces the strain on the garbage

5) What are the pros and cons of pooling components?  The pros are
response times, managed number of instances in the system, and reduced
on the garbage collector.  The cons are larger initial memory footprint,
longer initialization times.

A real world example is Apache Cocoon 2.  On my test system (Win2K, JDK
Tomcat 3.3b2, Cocoon 2.0a7) with the application I created for a client,
Tomcat and Cocoon weigh in at approximately 40 MB after heavy load is
However, once we are at peak memory usage (40-50 MB), it does not
any more memory.  It does keep pace quite well--I have tested it with
200 page loads per second sustainable (pages results were 1.2K in size)
was 240 KB/sec.

On contrast: IBM WebSphere on startup (not one request yet) weighs in at
impressive 60 MB on the same system.

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

View raw message