cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Fortress Migration Strategy
Date Thu, 16 Oct 2003 15:27:18 GMT

On Thursday, Oct 16, 2003, at 16:29 Europe/Rome, 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.

Question out of simple curiosity and/or ignorance: is the 
instrumentation JMX aware?


View raw message