Chris McDonough wrote:
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 :-).
I think Xron could work with anything that has "trigger" and "disarm" methods, that gets put into the Schedule catalog.
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?
What if you want a small job to be done every 30 seconds?
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?
Which separate thread? Do you create a new ZODB thread? That sounds as if it might use quite a few resources. Is there a Zope API for making ZODB threads call methods on objects, as signalled by other threads? I'm guessing the easiest way to do that is to use Client.py to make a new http 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?
I'd really like to see a scheduler as a standard part of Zope. I think it would be good to have scheduled methods called from within Zope, rather then going through http. I don't know enough about how ZPublisher/ZODB works to know where to start this though. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net