cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: CommandManager issues [was Re: Releasing 2.1.1?]
Date Sun, 31 Aug 2003 13:10:40 GMT
On Sat, 2003-08-30 at 17:24, Bruno Dumon wrote:
> On Sat, 2003-08-30 at 15:20, Giacomo Pati wrote:
<snip/>
> > I like the way how the Cornerstone Scheduler recently integrated by
> > Carsten more than the CommandManager way because of its
> > componentisation. Still, I like to see a Scheduler as a single component
> > definition in the xconf file. Today we need at least three component
> > definitions (Scheduler, ThreadManager, TimeScheduler) as well as one for
> > each Target. I think this can be made much easier, like:
> > 
> >   <scheduler logger="scheduler">
> >     <triggers>
> >       <trigger name="mytarget"
> >                class="my.comp.MyTarget"
> >                logger="mytarget">
> >         <timed type="crontab">
> >           <month> -1 </month>
> >           <weekday> SUN </weekday>
> >           <day> * </day>
> >           <hour> 9-17/2 </hour>
> >           <minute> */5 </minute>
> >         </timed>
> >       ...
> >     </triggers>
> >   </scheduler>
> > 
> > In the above, triggers are handled as Avalon components and the
> > scheduler takes care of instatiation and the lifecycle stuff.
> > 
> > Unfortunately, the Cornerstone Scheduler toolkit doensn't offer a full
> > crontab like specification of defining trigger point in time like I've
> > used above (and I'd be happy to have).
> > 
> > My suggestion (which I can implement if accepted) is to have a
> > Scheduler that is able to do the above by use of the CommandManager
> > given someone can fix Doug Leas concurrent utilities with the patch
> > from Bruno.
> 
> great.

Or maybe not so great. I'm not sure the CommandManager is well suited
for a general purpose scheduler.

What follows now should be read with a 'AFAIU' disclaimer:

All commands added to the CommandManager are executed sequentially and
on one thread. So if there is one command that takes somewhat longer to
execute, it will block the execution of other commands. This may be fine
for management-tasks which should be executed repeatedly (but not at
fixed times), but for a scheduler I would expect a command to be
executed at the configured time.

This could be solved by creating a different CommandManager for each
scheduled task, since multiple CommandManagers can be executed in
parallel. But then you'd still want to use a different ThreadManager
than the TPCThreadManager, since that will block when all threads are in
use.

The result will however be rather overkill IMHO: even commands that need
to be executed only weekly, will be checked every 100 ms (= sleeptime
parameter) to see if they need to be executed.

Conclusion: while this event-based infrastructure is quite cool, I'm not
convinced yet it is good for scheduling-purposes.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message