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 14:16:46 GMT
Vadim Gritsenko wrote:

> 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.
> Hm...
>>> 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.

You're right that when the first http request hits the servlet engine, 
the following occurs
- call CocoonServlet.init()
-     CocoonServlet.createCocoon()
-     Cocoon.initialize()
-     Load all components including RunnableManager
- end CocoonServlet.init()
- CocoonServlet.service()

Now CocoonComponentManager uses an InheritableThreadLocal that clones 
the environment stack in child threads.

So this stack is cloned not when the RunnableManager is created, but 
when it needs to create a new thread. So actually I'm wrong in saying 
the parent thread is the one processing the very first request. It 
actually can be any of the servlet engine's threads... or none if the 
server is idle when a background thread is created.

Which actually makes this bug likely to happen when the server is under 
high load.

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

Exactly. And my modifications ensure this CAN NOT happen, by simply 
suppressing the automatic inheritance of environment stack between child 
threads and their parent.

For places where we *need* inheritance to happen such as in parallel 
include transformer, we now MUST use CocoonThread that does the 
environment stack copy, thus preserving the information needed to 
correctly resolve URIs in background threads. And in that case, we 
cannot use RunnableManager since its threads don't (and shouldn't) 
inherit the environement stack.

>>> 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 
> queue,max-pool-size=2147483647,min-pool-size=1,priority=5,isDaemon=true,keep-alive-time-ms=60000,block-policy=ABORT,shutdown-wait-time-ms=-1

The difference between min-pool-size and max-pool-size is key here, as 
it indicates other threads will be created later, i.e. after 

> 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? :-?

The asynchronous nature of threads combined with the create-on-demand 
behaviour of pools.


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

View raw message