cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henrik Gustafsson" <henrik.gustafs...@telepo.com>
Subject Re: Implementation of the Continuations checker
Date Wed, 03 Nov 2004 06:41:44 GMT
> From: "Giacomo Pati" <giacomo@apache.org>
>
> 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?

And you will never need to cancel a scheduled command, or?

/Henrik Gustafsson 


Mime
View raw message