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
CocoonServlet.init().
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
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
