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]
