cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: CommandManager issues [was Re: Releasing 2.1.1?]
Date Tue, 02 Sep 2003 13:52:45 GMT
Bruno Dumon wrote:

> Or maybe not so great. I'm not sure the CommandManager is well suited
> for a general purpose scheduler.
> What follows now should be read with a 'AFAIU' disclaimer:
> All commands added to the CommandManager are executed sequentially and
> on one thread. So if there is one command that takes somewhat longer to
> execute, it will block the execution of other commands. This may be fine
> for management-tasks which should be executed repeatedly (but not at
> fixed times), but for a scheduler I would expect a command to be
> executed at the configured time.

The number of threads is configurable.  By default it is based on a function
of the number of processors.  In Cocoon it is currently 1 thread per processor
(plus one to manage the queue).  If you have two processors, you have two
threads.  Alternatively you can implement two threads per processor (works
well in most situations).  This approach makes sure that long running tasks
won't block all other items in the queue.

The Scheduler/ThreadPool combo you have with the Cornerstone components does
not give you anything more in this area.  The queue is moved to the Scheduler,
and the ThreadPool will block until a thread is made available.  The main
difference is that most folks typically assign more threads to the ThreadPool
than you have assigned to the ThreadManager.

> This could be solved by creating a different CommandManager for each
> scheduled task, since multiple CommandManagers can be executed in
> parallel. But then you'd still want to use a different ThreadManager
> than the TPCThreadManager, since that will block when all threads are in
> use.

Huh?  No.  The ThreadManager does the actual execution.  The CommandManager
merely organizes the commands and sets them up in the queue.

> The result will however be rather overkill IMHO: even commands that need
> to be executed only weekly, will be checked every 100 ms (= sleeptime
> parameter) to see if they need to be executed.
> Conclusion: while this event-based infrastructure is quite cool, I'm not
> convinced yet it is good for scheduling-purposes.

No matter how you slice it, even the Scheduler has this tradeoff.  You can
set the sleeptime longer if you never have anything checked less then 5 second
intervals or minute intervals, but in the end, the overhead of checking the
commands every 100 ms is so minimal that you would never see it.  Esp. since
that checking is done asynchronously from your critical path.  There is a
dedicated thread in each case that makes the checks for you--essentially
the only difference is in how many other components are needed to get the
job done.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message