Return-Path: 
 <dev-return-47139-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 11727 invoked from network); 31 Aug 2003 13:15:19 -0000
Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 31 Aug 2003 13:15:19 -0000
Received: (qmail 17663 invoked by uid 500); 31 Aug 2003 13:15:06 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 17564 invoked by uid 500); 31 Aug 2003 13:15:05 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 17531 invoked from network); 31 Aug 2003 13:15:04 -0000
Received: from unknown (HELO astra.telenet-ops.be) (195.130.132.58)
  by daedalus.apache.org with SMTP; 31 Aug 2003 13:15:04 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP id 1DE8C37EF7
	for <dev@cocoon.apache.org>; Sun, 31 Aug 2003 15:15:00 +0200 (MEST)
Received: from yum.ot (D5774E46.kabel.telenet.be [213.119.78.70])
	by astra.telenet-ops.be (Postfix) with ESMTP id B4A5B37FC2
	for <dev@cocoon.apache.org>; Sun, 31 Aug 2003 15:14:59 +0200 (MEST)
Subject: Re: CommandManager issues [was Re: Releasing 2.1.1?]
From: Bruno Dumon <bruno@outerthought.org>
To: dev@cocoon.apache.org
In-Reply-To: <1062257067.14367.384.camel@yum.ot>
References: <Pine.LNX.4.53.0308301140420.31893@lapgp.otego.com>
	 <1062257067.14367.384.camel@yum.ot>
Content-Type: text/plain
Organization: Outerthought
Message-Id: <1062335416.14373.441.camel@yum.ot>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Sun, 31 Aug 2003 15:10:40 +0200
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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