cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: Implementation of the Continuations checker
Date Wed, 03 Nov 2004 06:17:20 GMT
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

Mime
View raw message