cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Weird multithreading bug in Cron block
Date Thu, 09 Jun 2005 13:02:40 GMT
Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>> Carsten Ziegeler wrote:
>>> Sylvain Wallez wrote:
>>>> So IMO, we should change the way environment inheritance between 
>>>> threads is managed:
>>>> - if a child thread runs in the scope of its parent, then a special 
>>>> CocoonThread class (extends Thread) should be used, which will copy 
>>>> the needed environment data before launching its Runnable.
>>>> - normal threads created with "new Thread()" inherit nothing and 
>>>> can therefore work in a clean environment.
>>>> This approach requires two changes in the 2.1 code base (haven't 
>>>> checked 2.2 yet):
>>>> - DefaultIncludeCacheManager.load() in o.a.c.transformation.helpers
>>>> - maybe PortalManagerImpl.loadCoplet() in 
>>>> o.a.c.webapps.portal.components
>>>> In these two places, the CocoonThread proposed above have to be 
>>>> used to inherit the parent environment. In all other places where 
>>>> "new Thread()" is called, inheriting the parent environment is not 
>>>> needed and worse, can be harmful.
>>> Looks ok for me; I always thought that we should create our own thread
>>> class, but never had time... ;)
>> Great! I'm doing it right now as my customer is waiting for the 
>> bugfix :-)
> Please stop.
> RunnableManager does not create threads, it uses thread pool, threads 
> from the pool HAVE NO inherited variables.

Vadim, please read my explanation. Threads from the pool HAVE inherited 
variables from the thread that processed the first http request, that 
led to loading cocoon.xconf and created the thread pool.


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message