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-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?
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=10617480632&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: > > > > > > > > > > > > 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 [EMAIL PROTECTED] [EMAIL PROTECTED]
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-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 [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: [BUG] Expired Continuations are not cleaned up?
On Tue, 26 Aug 2003, Carsten Ziegeler wrote: > Bruno Dumon wrote: > > > > > > > > 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?
Bruno Dumon wrote: > > > > 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 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/ > >
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]
Re: [BUG] Expired Continuations are not cleaned up?
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
[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/