On Mon, 1 Sep 2003, Andreas Hochsteger wrote: > 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.
I've seen it some time ago but thought it is quite too much for a simple cron mechanism we are discussing here. Any other thoughts? > > Here's another one: > http://jcrontab.sourceforge.net/ It's (L)GPL > > 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 > > > > > > > -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
