Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Wed, 3 Nov 2004 07:17:20 +0100 (CET)
From: Giacomo Pati <giacomo@apache.org>
To: dev@cocoon.apache.org
Subject: Re: Implementation of the Continuations checker
In-Reply-To: <418849B4.6050900@reverycodes.com>
Message-ID: <Pine.LNX.4.61.0411030706140.11199@lapgp.otego.com>
References: <4183C582.5010004@dslextreme.com>
 <3AC7F738-2A9D-11D9-AD9E-000D93C1F3E2@hippo.nl>
 <Pine.LNX.4.61.0410302056480.9982@lapgp.otego.com>
 <8D3AA844-2AB4-11D9-AD9E-000D93C1F3E2@hippo.nl>
 <Pine.LNX.4.61.0411022228060.10023@lapgp.otego.com>
 <418849B4.6050900@reverycodes.com>
X-GPG-PUBLIC_KEY: 
 http://pks.gpg.cz:11371/pks/lookup?op=get&search=0x371005D8BA4A9F94
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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