Sky Torch wrote: > > Hello, > > are components in avalon supposed to be multi-thread safe? it seems that > it's using single-thread model. if so, how to improve through-put of the > system - i understand there's a pool impl, how to enable a component pool, > is it a big memory consumption, what's cons and pros of doing this, etc. ?
1) It is not always possible to be ThreadSafe--but it is preferred. that way You only have to have one instance of the component. 2) Improving through-put of the system: Excalibur's ComponentManager assumes that unless otherwise specified we are dealing with SingleThreaded components. That means that a new component instance is created for every lookup. This is not always desirable because it puts allot of stress on the garbage collector. For that reason, if a Component cannot be ThreadSafe, then it is preferred for it to be Poolable. Please note that those three different "Lifestyles" are interfaces that a Component can implement. org.apache.avalon.framework.thread.SingleThreaded ------------------------------------------------- A new instance is created for every lookup. It is the default because it is the safest assumption. However it should only be implemented if the component is not reentrant (i.e. only useable one time). org.apache.avalon.framework.thread.ThreadSafe --------------------------------------------- One instance is created and shared to all Components who look it up. It can only be used if the interface and the component is truly thread-safe. That means the code is reentrant, and no state is maintained between method calls. org.apache.avalon.excalibur.pool.Poolable ----------------------------------------- A set number of instances are created and passed to components that look it up. It should be used when code cannot be threadsafe due to maintaining state between method calls but the component is reentrant. The set number of available components reduces the strain on the garbage collector, thus increasing the overall load capacity and throughput of your system. org.apache.avalon.excalibur.pool.Recyclable ------------------------------------------- The same as Poolable, but there is an extra method that is called to reset the Component back to the original state. 3) How to enable a component pool: implement the Poolable or Recyclable interfaces and use the Excalibur Component manager. 4) Is it a big memory consumption? It depends on the size and complexity of your component. The default pool implementation starts with 4 instances, and as demand requires it will grow to 16 instances. If demand exceeds that, the pool implementation will create new instances, but destroy them when they are released. It is a soft resource limit--this guarantees success of the call, and manages memory consumption. Truth be told, it is cheaper on a Java system to keep components ready in a pool than it is to create and destroy them on every request. It reduces the strain on the garbage collector. 5) What are the pros and cons of pooling components? The pros are quicker response times, managed number of instances in the system, and reduced load on the garbage collector. The cons are larger initial memory footprint, and longer initialization times. A real world example is Apache Cocoon 2. On my test system (Win2K, JDK 1.3, Tomcat 3.3b2, Cocoon 2.0a7) with the application I created for a client, Tomcat and Cocoon weigh in at approximately 40 MB after heavy load is applied. However, once we are at peak memory usage (40-50 MB), it does not require any more memory. It does keep pace quite well--I have tested it with 200 page loads per second sustainable (pages results were 1.2K in size) which was 240 KB/sec. On contrast: IBM WebSphere on startup (not one request yet) weighs in at an impressive 60 MB on the same system. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
