Re: [BUG] Expired Continuations are not cleaned up?
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, SN AG http://radio.weblogs.com/0107211/
RE: [BUG] Expired Continuations are not cleaned up?
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?
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?
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-devw=2r=1s=remove+need+for+cornerstone+jarsq=b more specifically: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104628525923843w=2 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: [BUG] Expired Continuations are not cleaned up?
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-devw=2r=1s=remove+ne ed+for+cornerstone+jarsq=b more specifically: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104628525923843w=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?
I'm cc'ing [EMAIL PROTECTED] since they are probably more knowledgeable on this. See here for the full thread: http://marc.theaimsgroup.com/?t=10617480632r=1w=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-devm=104628525923843w=2 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [BUG] Expired Continuations are not cleaned up?
Hi Carsten, have you looked at http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105455074718424w=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?
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
[EMAIL PROTECTED] [EMAIL PROTECTED]
