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 and
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
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 launching
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
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
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
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
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
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
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
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
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
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
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
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,
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
16 matches
Mail list logo
