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?
I'd imaging the need for different task priorities (cinclude is normal priority, janitor is high), but what are the use cases for multiple thread pools?
Vadim
