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