Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 10997 invoked from network); 21 Feb 2001 13:44:46 -0000 Received: from fw.infoplanning.net (HELO infoplanning.com) (@209.8.58.131) by h31.sny.collab.net with SMTP; 21 Feb 2001 13:44:46 -0000 Received: (qmail 8389 invoked from network); 21 Feb 2001 13:47:05 -0000 Received: from unknown (HELO apache.org) (192.168.0.189) by inet with SMTP; 21 Feb 2001 13:47:05 -0000 Message-ID: <3A93C58E.B84B4AD@apache.org> Date: Wed, 21 Feb 2001 08:41:34 -0500 From: Berin Loritsch X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [C2]: Component Pooling and recycling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Carsten Ziegeler wrote: > > Using the latest cvs of C2, I have the following questions/remarks to the component pooling: > > Questions first: > 1. Looking up a component using the ComponentManager: > - Am I right that when the component is not Poolable I always get the same instance? No. Some are Factory components and are created fresh each time. If it is marked ThreadSafe, then you should get the same instance everytime. > - When the component is Poolable (or PoolClient) is it the response of the "looking up component" to put it back into the pool ? Unfortunately, that is the way it is. This does not change even when we are using the Pool interface like it was meant to be used (get/put). BTW: the "looking up component" is called a Composer--it even has an interface. > 2. Is it correct that Actions are never pooled or recycled? Yes. They are ThreadSafe by design, and so should be one instance for all time. > Now the remarks: > > 3. If a sitemap component is only Recyclable (without Poolable or PoolClient) it is not recycled. True. Recyclable does not necessarily mean Poolable (Not sure of the reasoning, but that's the way the framework is set up). The recycle() method is used to "reset" the component back to it's original status. > 4. If a sitemap component is only Poolable but not PoolClient it is not put back into the pool. That is an unfortunate side effect of the way the current ComponentManager/Selector interface is. If they had a put() method to return the Component on general principle, then it would make for a more elegant solution. The temporary solution is to make anything that is Poolable a PoolClient. > I would suggest to change the behaviour of 3. and 4. that Recyclable sitemap components are always recycled and that Poolable sitemap components are alyways returned to the pool - regardless if they declare PoolClient or not. They used to be simply Poolable, and not PoolClients. The PoolClients were created as a method of actually returning the Components to the Pool. Otherwise what we have is a factory method that simply creates more and more components all the time. What's worse, they have a reference on them in the pool, so they are never garbage collected. Any Poolable client should be made PoolClients, and any usage of a PoolClient should call the returnToPool method. Also, the recycle() method is called by the ComponentPool. In any other context, it's really not useful. > If there are no objections against the changes I will do them. The Pool code does need to be optimized, but let's standardize on all Poolable Components should be PoolClients--otherwise you will find that no Component can be returned to the pool without a reference to the pool.