cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hochsteger <e9625...@student.tuwien.ac.at>
Subject Re: CommandManager issues [was Re: Releasing 2.1.1?]
Date Mon, 01 Sep 2003 05:57:02 GMT
Hi!

Just in case you didn't know:
Did you have a look at the Quartz Scheduler?
http://www.part.net/quartz.html
http://www.part.net/quartz_features.html
Perhaps it already does what you need.
It's licensed under a BSD and Apache-Style license.

Here's another one:
http://jcrontab.sourceforge.net/

I found the links on this page:
http://wiki.cocoondev.org/Wiki.jsp?page=WyonaScheduler

Bye,
	Andreas

Giacomo Pati wrote:
> On Sun, 31 Aug 2003, Bruno Dumon wrote:
> 
> 
>>On Sun, 2003-08-31 at 20:38, Giacomo Pati wrote:
>>
>>>First, if you look at the Cornerstone Scheduler you'll see that the
>>>ability to define repeated tasks are somehow limited. Business apps can
>>>easily request administration tasks to be run twice a day on work days.
>>>To define this with the Cornerstone Scheduler you'll need to add 10
>>>'cron' entries to it. This is why I'd like to extend it using the unix
>>>cron direction to define ranges and list of timing aspects. But then
>>>you're faced with the problem of defining sleep time for efficient use
>>>(which you need to be able to cooperate in the Cornerstone Scheduler
>>>machinery).
>>>
>>>The unix cron daemon runs every minute to check if there are any jobs to
>>>run. It checks initially creating bitsets for the minute, hour, day,
>>>month, and weekday definition for each task. This makes it easy to
>>>check whether a task has to be launched. I still haven't found an
>>>algorithm (and I think there isn't an easy one available) to determine
>>>the sleep time until the next task is due.
>>
>>Ah, didn't think that far.
>>
>>
>>> Thus, a check every minute
>>>isn't much but still 1440 times a day.
>>
>>But a lot less then the 864000 times a day in case of a check every 100
>>ms :-)
> 
> 
> Sure.
> 
> 
>>>The other thing to respect if you'd like to go as efficent as possible
>>>is the determination of Threads you'll need to run each cron task at the
>>>time specified. But this needs knowledge about how much elapsed time a
>>>task need to run to decide if you need one or two thread to complete to
>>>task defined neat in time to each other. If you have an algorithm for
>>>this you'll be able to define the maximum numbers of Thread you'll need.
>>>Otherwise you allocate a separate Thread per defined task.
>>>
>>>The consequences are that probably the easiest solution to a (more or
>>>less) complete Cron like Scheduler is an own heart beat of one minute to
>>>check for task to launch and a pool of Threads as big as you have task
>>>to process. As it seems Doug Leas concurrency tools could be configured
>>>to be as resource sparing as possible (have a look at
>>>http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.html)
>>
>>Yep, I think that will be fine too.
> 
> 
> Ok, so I'll gona build up a Scheduler based on its own heart beat (own
> Thread) with Crond expressions for timing specifications that uses a
> PooledExecutor for the Triggers in the size of the numbers of Task
> defined in the configuration but with lazy construction of Thread
> objects. This will not need any additional jars and the ones introduced
> by the Cornerstone Sccheduler can be eliminated again. Is everybody
> happy with that?
> 
> --
> Giacomo Pati
> Otego AG, Switzerland - http://www.otego.com
> Orixo, the XML business alliance - http://www.orixo.com
> 
> 


Mime
View raw message