cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <>
Subject Re: creating Overflow Resource
Date Thu, 19 Apr 2001 20:58:19 GMT
giacomo wrote:

> On Thu, 19 Apr 2001, Berin Loritsch wrote:
>> giacomo wrote:
>>> 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
>>>>> 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?
>> I thought the contract with Actions stated that they _must_ be made
>> threadsafe and reentrant.  If this is not the case, then the ThreadSafe
>> interface should _not_ be included in the interface that describes an
>> Action.
>> In all reality, no work interface should extend a lifestyle interface
>> unless by the contract of the API it _must_ be enforced that way.
>> The decision of the lifestyle of a component should be done at the last
>> possible moment (much like making methods "final" in Java).  Once set,
>> they should never be over-ridden.  The ambiguities that arise over
>> lifestyle conflicts should be avoided if at all possible.
>> If we need to change the interface of some of the work interfaces to
>> not explicitely determine it's lifestyle, then let's do that.  The
>> Action interface is a prime example of something where if you don't
>> want it ThreadSafe, then the work interface should not specify it
>> that way.  The SitemapComponent is a prime example of something that
>> *requires* all implementing classes to be Poolable or SingleThreaded
>> (preferably Poolable).
>> The lifestyle and work interfaces are separate concerns, and should
>> only be merged when you are sure of the contract (e.g. with the
>> final implementation, or enforcing a contract in the interface).
> ok, convinced. We have to cleanup the interfaces from the jaxpParser

A request (I think there is avalon people 'round here :) ).

Could avalon check for multiple life-cycle implements declared and 
complain loudly upon configuration of components?

I don't think it has a heavy overhead in terms of resources, and it 
would enhance greatly usability of the framework.

I could take a look at this if someone points me to the classes doing 
the work in Avalon.

I already catched a similar problem, where a class (AbstractXMLProducer, 
I think) was declared as Recyclable, with a recycle method and then, 
like three levels down the inheritance hierarchy, recycle() was 
reimplemented without calling super, possibly because the intermediate 
classes were not declared as Recyclable.

OTOH, if the Recyclable interface is declared only at the bottom of the 
hierarchy, the implementor needs to understand how to recycle all super 
classes, which can lead to implementation problems.

Java has no way to specify the kind of thing needed here (compulsory 
super call) except for default constructors, and this kind of bugs turn 
quickly into debugging nightmares.

To unsubscribe, e-mail:
For additional commands, email:

View raw message