cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Weird multithreading bug in Cron block
Date Thu, 09 Jun 2005 13:26:00 GMT
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>> Remedy is to use thread pool(s), and not create local Threads - with 
>> the exception of situation when local thread lives no longer than 
>> original request.
> I used the scheduler's thread pool, and that's when the problem appeared.


>> If thread lives longer than request, use RunnableManager (or Cron), 
>> which are using thread pools. Thread from the thread pool should be 
>> set up with environment / processor, and it will be independent of 
>> http environment which triggered the job.
> Yes, I know that (having largely contributed to the CocoonJobExecutor). 
> The problem is the inheritance of the enviroment stack between threads 
> (either in the pool or brand new ones) and their parent, which happens 
> to be the servlet engine's thread that processed the very first request 
> in the case of RunnableManager.

Wait a sec, RunnableManager is setup when Cocoon servlet is initialized, and 
this is happening on the web application startup. At that time, there is no any 
environemnt setup - as no Servlet.process() was called yet. If yours 
RunnableManager is setup during Servlet.process(), it's some other problem, IMHO.

Anyways, RunnableManager's pools MUST NOT inherit any variables, IMHO. I think 
you meant the same.

>> CocoonQuartzJobExecutor already has enterEnv/leaveEnv, so it should 
>> work, if you have issues with it - what are they?
> Well, read the explanation above :-)

Did not made sense to me :-( I clearly see each time in the logs:

INFO  (2005-05-30) 23:18.23:295 [core.runnable] (Unknown-URI) 
Unknown-Thread/DefaultRunnableManager: ThreadPool named "daemon" created with no 

So pool has been created before any http environment has been created, and from 
my reading of InheritableThreadLocal javadoc, it creates a copy of self for the 
child thread, not reference - so threads are not sharing same ThreadLocal, so 
this pool should not ever get a http environment.

What's missing? :-?

> If a CronJob uses the SourceResolver to process a "cocoon:" URI, the 
> corresponding pipeline occasionally gets recycled in the middle of its 
> processing.

Is it reproducable with the samples? Probably adding pipeline with a delay will 
show this?

Sylvain Wallez wrote:
 > 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.

I did read now (email is async!) :-)

I don't see the behavior you are describing. Pools are created way before that.


View raw message