Vadim Gritsenko wrote:
Sylvain Wallez wrote:
- core: DefaultRunnableManager
The thread pool can be created lazily when the first Runnable is
executed.
Resulting pool will not behave same as with eager loading, for two
reasons:
(1) there are 5 references to InheritableThreadLocal in Cocoon code,
Using InheritableThreadLocal with the RunnableManager is *intrinsically
broken* :
- threads managed by the pool are not children of the current thread,
- the values for InheritableThreadLocal are set only once, when the
child thread is created [2].
I learned this the hard way after spending several days fighting nasty
random NPEs when running pipelines in CronJobs [1].
So let's check the uses of InheritableThreadLocal. I found only 4 of
them (what is your 5th?)
* batik block, SourceProtocolHandler:
Inheritance is for the hypothetical case where Batik would creates child
threads. Now I also found that references to this class are commented
out in SVGSerializer, meaning this class is actually never used ?!?!
* portal block, pluto/adapter/PortletAdapter:
Same as above, for the hypothetical case where Pluto would create
threads. Now this variable is set() but never get()!!! So we could
remove it completely. Carsten?
* portal block, util/ReferenceFieldHandler:
This one seems more problematic, as it has a number of child classes
which I don't know that they're about.
* portal block, wsrp/adapter/WSRPAdapter:
Don't have the slightest idea on how the "currentCopletInstanceData" is
used :-/
Carten, can you explain why you need InheritableThreadLocal and not only
ThreadLocal?
and (2) initialization Thread is not the same as thread making
request. It could be from different ThreadGroup, even.
Is that a problem?
Sylvain
[1] http://marc.theaimsgroup.com/?t=111816385600002&r=1&w=2
[2]
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/InheritableThreadLocal.html
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
