Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Thu, 16 Oct 2003 17:27:18 +0200
Subject: Re: Fortress Migration Strategy
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Stefano Mazzocchi <stefano@apache.org>
To: dev@cocoon.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F8EAB3A.8050501@apache.org>
Message-Id: <3A6D1130-FFED-11D7-811E-000393D2CB02@apache.org>


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?

--
Stefano.