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