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