[Zope-dev] Xron fragility

[Kapil Thangavelu]

Chris McDonough wrote:
> 
> > It is the Xron DTML Method's responsibility to reschedule itself.
> > It could be its first duty, however. Then again, as all the work happens
> > inside a ZODB transaction, it doesn't matter when the reschedule
> > happens.
> 
> I understand.
> 
> 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 :-).

My two biggest problems with the XRON facility are the Catalog and the
need for speciality methods. 

I was thinking a more useful model might be something along the lines of
a unix cron. each user having access to their own cron tab, via some
manage methods, and the methods listed would execute as the user.

the hole trigger/disarm methodology to me seems a bit hokey and fragile.

i can see the utility in offering up traditional zope semantics of users
creating objects, but i really think that scheduling is something that
should be part of the core and offered as a service to users.


> > > 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.

this model has problems when new jobs (for immeadiate execution) are
entered after the system sleeps. i think it should it taken into account
that people will use this dispatching thread to achieve async operations
on a request, and that these might need to be done immeadiately.

> 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:

the same problem applies, a solution might be a timer and a signal
handler to catch a signal event when a new job is entered into the
system. events could be managed as some sort of collection of linked
lists (or whatever ds). 

>     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))
> 
> > It uses Client.py to run a job.
> 
> Why is this?  This doesn't make any sense to me on its face.  Why not just
> call the method from a separate thread?

i played around with this in a monitor thread and you just can't achieve
the proper semantics to execute an arbitray zope method. you have to
recreate the request, response as well as have all the required support
modules (DTML, tracebacks, etc) to successfully call a method, you are
in essence reduplicating the publishing machinery. i tried to think of a
way to get around this but i came up short. you can still access
variables and simple methods.

> > > What are other threads in Xron doing while the Dispatcher thread is
> hosed?
> > > What are the other threads?
> >
> > There are no other threads in Xron.
> > Xron creates a single thread to do all event dispatching. The work is
> > done in Zope ZODB threads (or whatever the correct terminology is). The
> > dispatcher thread communicates with a ZODB thread by using Client to
> > make a web request.
> 
> I see... would it be naive if I were to say that I think that a scheduler
> should fire off threads of its own and not rely on an external facility to
> run the jobs?

the dispatcher thread itself has a connection to the ZODB, its using
client as RPC to invoke the methods on Publishing threads. Since there
is a hardcoded limit to ZODB connections firing off more connections
does not seem like a good idea.

> > Xron usually makes requests as the anonymous user. However, I've patched
> > my Xron to make requests as XronUser by hardcoding (!) the username and
> > password for that in the RPC.py module of Xron. Then, I've manually
> > created a XronUser user in my root user folder. I give XronUser the
> > local roles needed to run methods I want to be scheduled via Xron.
> 
> If this were handled not using Client.py, I think we could just use the
> security manager to change users.

the xron dispatcher has access to ZODB attrs, and simple methods. the
security manager would probably need to support semantics of retrieving
passwords so they can be set in the client.


btw, i'm interested in seeing scheduling get into the zope core as well.

Kapil