[Zope-dev] Xron fragility

[Loren Stafford]

From: "Chris McDonough" <chrism@digicool.com>


[snip]

> As a side note, I do not like the fact that Xron requires you to use
special
> DTML methods.  I suppose this is a requirement in this architecture
due to
> the fact they need to be autocataloged, but I don't really like that
feature
> either :-).

The use of special DTML methods was a intended as a "proof of concept"
as well as as a simple implementation route to get something running in
the short term. It would be preferable to have the ability to schedule
any method -- including python methods, perl methods, external methods,
....  However, any more general implementation has to address the same
issues addressed by the special DTML method of Xron:

1. Automatic reflection of changes to a method's scheduling parameters
in the dispatcher's table of scheduled methods. Xron DTML methods are
catalog aware for this reason. Autocataloging could clearly be
implemented by other means.

2. Making rescheduling decisions inside the scope of the current
transaction. Waking up the dispatcher (if the sleeping model is used)
when the schedule table changes. For these reasons, Xron DTML Methods
have "trigger" methods. A trigger method is like a __call__ method, but
it deals with the mechanics of scheduling while leaving __call__
available for calling the method in cases (like when debugging the core
logic of the method) when you don't want to mess with the schedule.

> > > What does the Dispatcher thread do?  Does it fire off worker
threads?
> >
> > Xron has a single dispatcher thread. This thread knows how long to
sleep
> > for until the next job needs to run.
>
> Do you think this is this any more effective than having a producer
thread
> do a lookup every minute to see what jobs are current, after which it
should
> put the current jobs in a queue?  E.g., as the "run" method of a
separate
> producer thread:
>
>     def
run(self,localtime=time.localtime,time=time.time,sleep=time.sleep):
>        while 1:
>             t = localtime(time())
>             sleeptime = (60 - t[SECOND])
>             sleep(sleeptime)
>             for event in self.eventdata.values():
>                 if event.isCurrent():
>
> self.outputqueue.put(EventWrapper(event,self.reportqueue))
>

I don't see much of a functional difference between a polling and a
sleeping model for the dispatcher. Both need a list of scheduled methods
(events). I chose the sleeping model because it eliminates any
granularity for the wakeup times. But it's not enough more complicated
that I would consider it a design issue.

[snip]

-- Loren