Vadim Gritsenko wrote:
<snip/>
and (2) initialization Thread is not the same as thread making
request. It could be from different ThreadGroup, even.
Is that a problem?
Actual problem is that RunnableManager's threads should not be
children of any request processing thread, and currently this is the
case because RunnableManager is initialized eagerly.
If RunnableManager's thread pools are created lazily (==children of
single request processing thread), following can happen:
* All threads in pools inherit locals of the request thread,
which is wrong.
Using inheritable threadlocals is wrong anyway with thread pools
* All threads will be created in the ThreadGroup of the request
processing thread, will attempt to modify said group, and
can fail with SecurityException (you can create thread in a
thread group only if you have modifyThreadGroup priviledge).
I don't see the point. Do you mean that the thread that initializes a
servlet is not the same and has different privileges than the one
processing the request?
* All threads will be limited to the priorities set for the
request processing thread's group priorities.
Ok.
* All threads will inherit isDaemon, priority, contextClassLoader
attributes of the execution thread. Both setPriority and setDaemon
require permissions configured.
Ok.
In short: request processing thread pool can be configured with
different priorities, different permissions than initialization
thread. Loading RunnableManager with lazy mode will hit these
restrictions.
Hence my request to load RunnableManager eagerly to avoid any possible
complications.
Ok, thanks for the explanations. RunnableManager is Startable again.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
