cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Alternatives to Poolable
Date Tue, 10 Feb 2004 10:38:24 GMT
I think there were a lot of discussions over the last years in the
Avalon list about a similar topic: making all components thread safe
and use a factory approach for poolable components. But unfortunately
all these discussions got very confusing for me and I couldn't follow
them :) So perhaps this is a topic for Avalon?

Carsten 

> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org] 
> Sent: Tuesday, February 10, 2004 11:31 AM
> To: dev@cocoon.apache.org
> Subject: [RT] Alternatives to Poolable
> 
> Found a very interesting read at
> http://www-106.ibm.com/developerworks/library/j-jtp01274.html?
> ca=drs-j0504
> 
> This articles explains the memory allocation and collection 
> strategies of modern JVM and show that object recycling and 
> pooling can cause more harm than good.
> 
> I've always been worried by the fact that most of our 
> stateful components are Poolable (stateless ones are 
> ThreadSafe) and not simply SingleThreaded.
> 
> We make them Poolable because their creation cost is high. 
> But why so? 
> Because the Avalon framework brings a lot of overhead to 
> object creation by going through the various lifecycle 
> interface, and because each of the created instances has to 
> perform repetitive actions that could be shared between the 
> various instances. The main cost in this area is parsing the 
> configuration, which is the same for all instances of a given 
> component.
> 
> This leads to identifying something I would call "component fields" 
> which are between static fields (system-wide values for a 
> class - identical for the various component declarations 
> using a class) and instance fields (specific to a given instance).
> 
> How can we solve this? I see two solutions:
> - define a new lifestyle that would ask the container to hold 
> those "component fields", and have them computed once at 
> startup by one instance of the component class. This strategy 
> is similar to PreparedMatcher.
> - avoid stateful component definitions everywhere it is 
> possible. For example (I already talked about this), the 
> Transformer interface, instead of being an XMLPipe (and thus 
> a ContentHandler), could be a factory with a single method 
> "getContentHandler" method.
> 
> These approaches can allow to remove most of the object pools 
> that are the most difficult point in tuning Cocoon for performance.
> 
> The first idea complexifies the contract between components 
> and the framework, which may not be a good idea (see [1] and 
> [2] for very interesting reads on this subject) whereas the 
> second approach requires some deep changes to what we have today.
> 
> These are random thoughts, but WDYT?
> 
> Sylvain
> 
> [1] http://lsd.student.utwente.nl/jicarilla/TooMuchMagic
> [2] 
> http://lsd.student.utwente.nl/jicarilla/StoryOfThe6LifecycleMethods
> 
> -- 
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, 
> Projects } Orixo, the opensource XML business alliance  -  
> http://www.orixo.com
> 
> 
> 


Mime
View raw message