Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
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
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
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
threa
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
ap
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
After second look, does not look too harmful, even though unnecessary.
Man, I spend two full days chasing the bug and finding its cause. I
don't call this unnecessary...
Now your turn to read email ;-) My guess there is a problem in your setup.
Vadim Gritsenko wrote:
After second look, does not look too harmful, even though unnecessary.
Man, I spend two full days chasing the bug and finding its cause. I
don't call this unnecessary...
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvain
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
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So IMO, we should change the way environment inheritance between
threads is managed:
- if a child thread runs in the scope of its parent, then a special
CocoonThread class (extends Thread) should be
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Sylvain Wallez wrote:
Weird, weird, weird! Anybody having a hint about why fireJob() is
doing this environment mixture?
Actually fireJobAt() is broken also when using another test case.
What's wrong with it?
Desperately searching for the
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So the question is:
- why is the pipeline automatically released? Is to avoid memory leaks?
Yes, in 2.1.x there was no good place for explicitly releasing the
pipeline; this required some incompatible changes we did in
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So IMO, we should change the way environment inheritance between
threads is managed:
- if a child thread runs in the scope of its parent, then a special
CocoonThread class (extends Thread) should be used, which will copy
th
Sylvain Wallez wrote:
Sylvain Wallez wrote:
Weird, weird, weird! Anybody having a hint about why fireJob() is
doing this environment mixture?
Actually fireJobAt() is broken also when using another test case.
What's wrong with it?
Desperately searching for the cause, I went back to basic
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So IMO, we should change the way environment inheritance between threads
is managed:
- if a child thread runs in the scope of its parent, then a special
CocoonThread class (extends Thread) should be used, which will copy the
needed environment
Sylvain Wallez wrote:
> So IMO, we should change the way environment inheritance between threads
> is managed:
> - if a child thread runs in the scope of its parent, then a special
> CocoonThread class (extends Thread) should be used, which will copy the
> needed environment data before launchi
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So the question is:
- why is the pipeline automatically released? Is to avoid memory leaks?
Yes, in 2.1.x there was no good place for explicitly releasing the
pipeline; this required some incompatible changes we did in 2.2; the
pipelines ar
Sylvain Wallez wrote:
> So the question is:
> - why is the pipeline automatically released? Is to avoid memory leaks?
>
Yes, in 2.1.x there was no good place for explicitly releasing the
pipeline; this required some incompatible changes we did in 2.2; the
pipelines are released there explicitly an
Sylvain Wallez wrote:
Hi all,
I'm currently working on a publication application with complex
database queries where we want to prefetch some of the pages linked to
by the page currently being produced, in order to speed up response
time on pages that are likely to be asked for by users.
T
Bart Molenkamp wrote:
A little bit off-toptic, but some time ago I used the pipeline machinery
to generate mail-content for users, somewhere at night by a CRON job.
For each user, the pipeline was called and the results were sent to that
user. Processing such a pipeline from CRON took about 2 se
A little bit off-toptic, but some time ago I used the pipeline machinery
to generate mail-content for users, somewhere at night by a CRON job.
For each user, the pipeline was called and the results were sent to that
user. Processing such a pipeline from CRON took about 2 seconds for each
mail, whil
18 matches
Mail list logo
