cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: [BUG] Expired Continuations are not cleaned up?
Date Mon, 25 Aug 2003 20:45:35 GMT
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 {

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, 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.


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                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message