Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 9787 invoked by uid 500); 19 Apr 2001 15:47:49 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 9622 invoked from network); 19 Apr 2001 15:47:46 -0000 Date: Thu, 19 Apr 2001 17:48:27 +0200 (CEST) From: giacomo X-X-Sender: To: Subject: Re: creating Overflow Resource In-Reply-To: <3ADEDF0E.33524963@apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Thu, 19 Apr 2001, Berin Loritsch wrote: > giacomo wrote: > > > > I think I've found the reason why C2 creates masses of Overflow > > Resources from JaxpParser. The JaxpParser itself states that it is > > ThreadSafe but extends AbstractXMLProducer which is Recyclable. The > > DefaultComponentHandler for this class first checks if it is Poolable > > (note that Recyclable exteds Poolable) and create a pool for it. This > > leads to the creation of new instances whenever a parser is lookup()ed. > > On the other side when the parser is released to the manager it is > > passed back to the handler which examines the interfaces implemented by > > the parser. The hnandler first tests if it implements ThreadSafe, (which > > the JaxpParser it does, and thus does not put it back to the pool. > > > > First we have to clean up the interfaces of the JaxpParser. > > > > Second, Berin, could you double check if the sequence of interface > > checks in the component management system in Avalon is correct? > > The affects of implementing conflicting interfaces like ThreadSafe, > Poolable, and SingleThreaded is undefined according to the Avalon Spec. > The interface definitely needs to be cleaned up. > > The way the ComponentHandler (the class that enforces the lifecycle > for a Component) works, is that it makes the assumption that the > class only implements one of the lifestyle (ThreadSafe, Poolable, > and SingleThreaded) interfaces. If it extends Poolable, it creates > a pool. This is usually the first check. If it is ThreadSafe, > it will instantiate an instance of the class and hold it until the > class is disposed. Finally if the Component is SingleThreaded, it > acts like a simple factory. This is not always the case. Take the Actions which extends ThreadSafe. But if someone writes a Action which can't be ThreadSafe (whatever the reason is) it should be able to "downgrade" the action to Poolable and the component management system should be able to take that into account, right? Giacomo > > On Component Return, I will double check the order of tests--but > the Component must only implement one of those lifestyle interfaces. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org > For additional commands, email: cocoon-dev-help@xml.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org