avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Fortress Migration Strategy
Date Thu, 16 Oct 2003 19:05:40 GMT


Berin Loritsch wrote:

> Berin Loritsch wrote:
>
>>
>> The core reason for this approach was a performance/resource issue.  
>> With
>> a pooled component, we run into the problem of having several copies of
>> this component for the same request for some reason.  In some ways 
>> this is
>> unavoidable.  However the overhead of looking it up and releasing it 
>> multiple
>> times resulted in alot of overhead.
>
>
> FYI, Fortress component pooling is *far* better than the ECM.  Much less
> synchronization overhead, and the pool grows naturally under load and
> cleans up after itself as load goes down.  It could get smarter, but for
> now it is better to see how things are doing.
>
> Also note that the pool sizes are instrumented for you so that you can
> attach the Avalon Instrument client to your Cocoon server and watch the
> pool sizes for your avalon components under load.  Really cool stuff.
>
> Merlin uses the same pooling mechanism as Fortress, but I am not sure
> if the pool sizes are instrumented yet.  


Just for reference - Merlin 2.1 used the same pooling mechanism
as Fortress.  The released Merlin 3.0 does not provide pooled object
support.  The reason was (a) that the pool implementation was tied to the
kenel implementation and I wanted to rethink this in terms of establishing
a pool manager implementation component (which in turn requires some work
inside the kernel to support facility deployment), (b) parameterization
of pools needs to be declared at the <component> directive level, and
(c) there were technical issues with the pool/event/concurrency jars that
were making like painful.

> That could be an improvement to Merlin to see in the near future.


I think we should be exposing instrumentable aspects via jmx.  This is
already in place within the Merlin kernel and a JMX manageble applicance
is the pipeline.  Both include active event motification of state change
which in turn can be handled by a JMX client.

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org



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


Mime
View raw message