You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/08/24 19:39:58 UTC
[BUG] Expired Continuations are not cleaned up?
Hi,
it seems that the CommandManager of the Excalibur Event package
is not working as expected. If you add a command to the sink
of the CommandManager it's never executed.
Unfortunately, this code is used in the ContinuationsManager
for testing against expired continuations. But the
execute() method of ContinuationInterrupt is never invoked!
So, it seems that there is a bug somewhere in the event package
and our manager is not working properly.
Why is the CommandManager instantiated in Cocoon.java, put
into the Context and get out of it in contextualize in the
ContinuationManagerImpl? The CommandManager is only used
there. IMHO it would be much cleaner to either move the
initialization to the ContinuationManagerImpl or to make
a real component out of it. Passing components in the context
seems to be a hack, no?
I think, a simple solution would be to switch to the cornerstone
scheduler component. This component works (see the scheduler sample
in the scratchpad) and removing the CommandManager usage should also
fix the shut-down problems with Tomcat entered as a bug that annoyes
many users.
But if someone is able to fix both problems in the event
package I'm fine with that as well of course.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/
Executing Pipelines from the Scheduler
Posted by Tony Collen <co...@umn.edu>.
Hi everybody,
I just noticed Carsten's scheduler in the scratchpad... finally, the
circle is complete! :) Since I'm not totally up to date on Avalon and
the Cocoon internals, I thought I'd ask: what's the best way of
activating a pipeline with the scheduler? This is probably a huge can
of worms, but I just wanna be able to trigger a request, even if it's
internal-only, to set off a pipeline and get some XSL results sent to
the disk.
Thanks,
Tony
RE: [BUG] Expired Continuations are not cleaned up?
Posted by Bruno Dumon <br...@outerthought.org>.
I'm cc'ing dev@avalon since they are probably more knowledgeable on
this. See here for the full thread:
http://marc.theaimsgroup.com/?t=106174806300002&r=1&w=2
On Tue, 2003-08-26 at 09:39, Giacomo Pati wrote:
> On Tue, 26 Aug 2003, Carsten Ziegeler wrote:
>
> > Bruno Dumon wrote:
> > >
> > > <SNIP/>
> > >
> > > one before and one after the ContinuationsInterrupt, and on my system
> > > (Linux, sun jdk 1.4.2-b28) the messages printed in the execute method
> > > are displayed every second, like it should. (this works without changing
> > > the threads-per-processor parameter)
> > >
> > Ok, I tested on W2k and Windows XP, sun jdk 1.4.1 and 1.4.2. Perhaps the
> > os is the difference?
>
> No! I've the same system where any additional Commands won't be
> triggered (Linux, sun jdk 1.4.2).
Did some further tests.
For me it doesn't work with 1.3.1_04-b02 (or more precisely: the tasks
are executed just once), and the first time I tried with 1.4.1-b21, the
tasks were executed only 3 times (but in further tests it kept going).
In any case, doesn't seem to be very reliable...
And now I just tried changing the threads-per-processor to 2 and then it
works with 1.3.1. Has anyone an explanation for this?
Could anyone of the avalon folks also tell if the remark about the
deadlock problem in the following message is still relevant?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104628525923843&w=2
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: [BUG] Expired Continuations are not cleaned up?
Posted by Bruno Dumon <br...@outerthought.org>.
I'm cc'ing dev@avalon since they are probably more knowledgeable on
this. See here for the full thread:
http://marc.theaimsgroup.com/?t=106174806300002&r=1&w=2
On Tue, 2003-08-26 at 09:39, Giacomo Pati wrote:
> On Tue, 26 Aug 2003, Carsten Ziegeler wrote:
>
> > Bruno Dumon wrote:
> > >
> > > <SNIP/>
> > >
> > > one before and one after the ContinuationsInterrupt, and on my system
> > > (Linux, sun jdk 1.4.2-b28) the messages printed in the execute method
> > > are displayed every second, like it should. (this works without changing
> > > the threads-per-processor parameter)
> > >
> > Ok, I tested on W2k and Windows XP, sun jdk 1.4.1 and 1.4.2. Perhaps the
> > os is the difference?
>
> No! I've the same system where any additional Commands won't be
> triggered (Linux, sun jdk 1.4.2).
Did some further tests.
For me it doesn't work with 1.3.1_04-b02 (or more precisely: the tasks
are executed just once), and the first time I tried with 1.4.1-b21, the
tasks were executed only 3 times (but in further tests it kept going).
In any case, doesn't seem to be very reliable...
And now I just tried changing the threads-per-processor to 2 and then it
works with 1.3.1. Has anyone an explanation for this?
Could anyone of the avalon folks also tell if the remark about the
deadlock problem in the following message is still relevant?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104628525923843&w=2
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [BUG] Expired Continuations are not cleaned up?
Posted by Giacomo Pati <gi...@apache.org>.
On Tue, 26 Aug 2003, Carsten Ziegeler wrote:
> Bruno Dumon wrote:
> >
> > <SNIP/>
> >
> > one before and one after the ContinuationsInterrupt, and on my system
> > (Linux, sun jdk 1.4.2-b28) the messages printed in the execute method
> > are displayed every second, like it should. (this works without changing
> > the threads-per-processor parameter)
> >
> Ok, I tested on W2k and Windows XP, sun jdk 1.4.1 and 1.4.2. Perhaps the
> os is the difference?
No! I've the same system where any additional Commands won't be
triggered (Linux, sun jdk 1.4.2).
>
> Carsten
>
>
>
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
RE: [BUG] Expired Continuations are not cleaned up?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bruno Dumon wrote:
>
> <SNIP/>
>
> one before and one after the ContinuationsInterrupt, and on my system
> (Linux, sun jdk 1.4.2-b28) the messages printed in the execute method
> are displayed every second, like it should. (this works without changing
> the threads-per-processor parameter)
>
Ok, I tested on W2k and Windows XP, sun jdk 1.4.1 and 1.4.2. Perhaps the
os is the difference?
Carsten
Re: [BUG] Expired Continuations are not cleaned up?
Posted by Bruno Dumon <br...@outerthought.org>.
On Sun, 2003-08-24 at 19:39, Carsten Ziegeler wrote:
> Hi,
>
> it seems that the CommandManager of the Excalibur Event package
> is not working as expected. If you add a command to the sink
> of the CommandManager it's never executed.
> Unfortunately, this code is used in the ContinuationsManager
> for testing against expired continuations. But the
> execute() method of ContinuationInterrupt is never invoked!
A good week ago, I happened to look at the CommandManager implementation
to find out how it works, to see if I could trust it, and it seemed to
do its job, so I was a bit suprised by this.
I now quickly tried adding two extra RepeatedCommands in the
ContinuationsManager like this:
m_commandSink.enqueue(new RepeatedCommand() {
public int getNumberOfRepeats() {
return -1;
}
public long getRepeatInterval() {
return 1000;
}
public long getDelayInterval() {
return 0;
}
public void execute() throws Exception {
System.out.println("hallo1");
}
});
one before and one after the ContinuationsInterrupt, and on my system
(Linux, sun jdk 1.4.2-b28) the messages printed in the execute method
are displayed every second, like it should. (this works without changing
the threads-per-processor parameter)
>
>
> So, it seems that there is a bug somewhere in the event package
> and our manager is not working properly.
>
> Why is the CommandManager instantiated in Cocoon.java, put
> into the Context and get out of it in contextualize in the
> ContinuationManagerImpl? The CommandManager is only used
> there. IMHO it would be much cleaner to either move the
> initialization to the ContinuationManagerImpl or to make
> a real component out of it. Passing components in the context
> seems to be a hack, no?
I share this feeling.
>
> I think, a simple solution would be to switch to the cornerstone
> scheduler component. This component works (see the scheduler sample
> in the scratchpad) and removing the CommandManager usage should also
> fix the shut-down problems with Tomcat entered as a bug that annoyes
> many users.
> But if someone is able to fix both problems in the event
> package I'm fine with that as well of course.
dito
I found the workings of the CommandManager rather strange: how it
continuously, every 100 ms (configurable), removes all items from the
m_delayedCommands list and then readds them. From a quick look,
cornerstone scheduler seems to follow the more traditional approach of
simply sleeping until the next task.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [BUG] Expired Continuations are not cleaned up?
Posted by Matthias Stöckel <Ma...@fztig938.bank.dresdner.net>.
Hi Carsten,
have you looked at
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105455074718424&w=2 ?
Increasing the "threads-per-processor" parameter seems to fix the bug
for me. But I think switching to cornerstone would be better, because
this doesn't resolve the shutdown problem with tomcat.
Cheers
Matthias
Carsten Ziegeler wrote:
> Hi,
>
> it seems that the CommandManager of the Excalibur Event package
> is not working as expected. If you add a command to the sink
> of the CommandManager it's never executed.
> Unfortunately, this code is used in the ContinuationsManager
> for testing against expired continuations. But the
> execute() method of ContinuationInterrupt is never invoked!
>
> So, it seems that there is a bug somewhere in the event package
> and our manager is not working properly.
>
> Why is the CommandManager instantiated in Cocoon.java, put
> into the Context and get out of it in contextualize in the
> ContinuationManagerImpl? The CommandManager is only used
> there. IMHO it would be much cleaner to either move the
> initialization to the ContinuationManagerImpl or to make
> a real component out of it. Passing components in the context
> seems to be a hack, no?
>
> I think, a simple solution would be to switch to the cornerstone
> scheduler component. This component works (see the scheduler sample
> in the scratchpad) and removing the CommandManager usage should also
> fix the shut-down problems with Tomcat entered as a bug that annoyes
> many users.
> But if someone is able to fix both problems in the event
> package I'm fine with that as well of course.
>
>
> Carsten
RE: [BUG] Expired Continuations are not cleaned up?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bruno Dumon wrote:
> > IIRC, the cornerstone scheduler was the orginal scheduler
> > used to expire continuations. I would need to delve into
> > the mail archives to retreive the reason that it was changed.
>
> I just did, see here:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=remove+ne
> ed+for+cornerstone+jars&q=b
>
> more specifically:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104628525923843&w=2
>
The cornerstone scheduler is released as an rc and is (again) in the
scratchpad/lib directory. It has a dependency to excalibur-thread
and cornerstone-threads. Now 5 (!) jars are required as one jar
contains the api and one the impl (for scheduler and threads).
Carsten
Re: [BUG] Expired Continuations are not cleaned up?
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2003-08-25 at 14:24, Michael Melhem wrote:
> On Sun, Aug 24, 2003 at 07:39:58PM +0200, Carsten Ziegeler wrote:
> > Hi,
> >
> > it seems that the CommandManager of the Excalibur Event package
> > is not working as expected. If you add a command to the sink
> > of the CommandManager it's never executed.
> > Unfortunately, this code is used in the ContinuationsManager
> > for testing against expired continuations. But the
> > execute() method of ContinuationInterrupt is never invoked!
> >
> > So, it seems that there is a bug somewhere in the event package
> > and our manager is not working properly.
> >
> > Why is the CommandManager instantiated in Cocoon.java, put
> > into the Context and get out of it in contextualize in the
> > ContinuationManagerImpl? The CommandManager is only used
> > there. IMHO it would be much cleaner to either move the
> > initialization to the ContinuationManagerImpl or to make
> > a real component out of it. Passing components in the context
> > seems to be a hack, no?
> >
> > I think, a simple solution would be to switch to the cornerstone
> > scheduler component. This component works (see the scheduler sample
> > in the scratchpad) and removing the CommandManager usage should also
> > fix the shut-down problems with Tomcat entered as a bug that annoyes
> > many users.
> > But if someone is able to fix both problems in the event
> > package I'm fine with that as well of course.
>
> IIRC, the cornerstone scheduler was the orginal scheduler
> used to expire continuations. I would need to delve into
> the mail archives to retreive the reason that it was changed.
I just did, see here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=remove+need+for+cornerstone+jars&q=b
more specifically:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104628525923843&w=2
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [BUG] Expired Continuations are not cleaned up?
Posted by Michael Melhem <mi...@managesoft.com>.
On Sun, Aug 24, 2003 at 07:39:58PM +0200, Carsten Ziegeler wrote:
> Hi,
>
> it seems that the CommandManager of the Excalibur Event package
> is not working as expected. If you add a command to the sink
> of the CommandManager it's never executed.
> Unfortunately, this code is used in the ContinuationsManager
> for testing against expired continuations. But the
> execute() method of ContinuationInterrupt is never invoked!
>
> So, it seems that there is a bug somewhere in the event package
> and our manager is not working properly.
>
> Why is the CommandManager instantiated in Cocoon.java, put
> into the Context and get out of it in contextualize in the
> ContinuationManagerImpl? The CommandManager is only used
> there. IMHO it would be much cleaner to either move the
> initialization to the ContinuationManagerImpl or to make
> a real component out of it. Passing components in the context
> seems to be a hack, no?
>
> I think, a simple solution would be to switch to the cornerstone
> scheduler component. This component works (see the scheduler sample
> in the scratchpad) and removing the CommandManager usage should also
> fix the shut-down problems with Tomcat entered as a bug that annoyes
> many users.
> But if someone is able to fix both problems in the event
> package I'm fine with that as well of course.
IIRC, the cornerstone scheduler was the orginal scheduler
used to expire continuations. I would need to delve into
the mail archives to retreive the reason that it was changed.
cheers,
Michael Melhem
>
>
> Carsten
>
> Carsten Ziegeler
> Open Source Group, S&N AG
> http://radio.weblogs.com/0107211/
>
>