cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Implementation of the Continuations checker
Date Fri, 05 Nov 2004 13:23:00 GMT
Giacomo Pati wrote:
> 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?

Yes, of course :)


> 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".

Ok, go ahead. It just means that users of BackgroundManager (such as include 
transfomer) should have thread pool name configurable. Probably we could supply 
two thread pools, one for request processing, and one for system tasks.

And still, there should be a way to configure thread pools' priority - as part 
of BackgroundManager configuration, I assume.

Vadim

Mime
View raw message