On Tue, 2 Nov 2004, Vadim Gritsenko wrote:
Giacomo Pati wrote:
Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
functionalities we are in need for the core (scheduling Runnables once,
with delays, periodically)
- Some stated that the cron block seems too heavy for that (I take that as
a veto :-)
- I'd like to have Thread spawning in one single component so that users
of "sophisticated" EAS can write their own implementation of the
following proposed interfaces.
A BackgroundManager/AsyncManager (name it as you like) manages ThreadPools (named and anonymous ones) and executions of Runnables using them:
interface ThreadPool { void execute( Runnable command ); TYPE getPROPERTY(); // what ever values should be exposed }
interface BackgroundManager { void execute( Runnable command ); *1 *a void execute( Runnable command, long delay ); *1 *b void execute( Runnable command, long delay, long period ); *1 *c void execute( String threadPoolName, Runnable command ); *2 *a void execute( String threadPoolName, Runnable command, long delay ); *2 *b void execute( String threadPoolName, Runnable command, long delay, long period ); *2 *c ThreadPool createPool( String name, ... ) *3 ThreadPool createPool( ... ) *4 }
*1 runs a Runnable in the default ThreadPool *2 runs a Runnable in a named ThreadPool *3 creates a named ThreadPool (shared usage of ThreadPools) *4 creates a anonymous ThreadPool (private usage by some client) *a runs command once *b runs command after a delay *c runs command periodically after a delay
A DefaultBackgroundManager implementation will create ThreadPools based on one of concurrent-utils Executors depending on the configuration (this is ready to use code from the cron block).
The settings of the default ThreadPool will be based on the current CommandManager configuration. The configuration of the default ThreadPool can be overwritten using normal configuration methods (see src/blocks/cron/conf/cron.xconf adding a name attribute). Named ThreadPools can be created at strartup by configuration.
What do you think about this as a replacement for the Event package?
Looks good to me (disclaimer: I've not examined event pacjage). One question: why multiple thread pools?
Have you looked at the thread pool in the cron block?
A thread pool consists of: - max. # of threads that run simultaneously - a possible queue to stack up ready to run Runnables
If you have a lot of short living Runnables at low priority (logically) you'd prefere to have a thread pool with only a few threads ready but a large queue. If you have some long running jobs to be done you'd like to have a pool of many threads. Thread pools is the way to balance "work to be done" with "resources needed for".
-- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
