At 11:32 2002-10-05 +0200, Joachim Werner said:
Hi All, I'm interested in starting to maintain Xron, if it has potential to be a stable products. From the code it doesn't seem to do any strange things, but I would like to know if anybody has experience of using it in a production environment, or any other experiences and that would recommend not using it in a production environment.
We are using it, but there seem to be some problems. One of them is that I frequently have cases where Xron doesn't reschedule properly (I am using the improved user interface stuff for Xron, so the bug could also be in there). What happens is that an event that is scheduled for daily execution at midnight will not be rescheduled for the next day after it was executed, but reset to the year 1970, which actually means it is switched off.
The other problem is more obvious, but still it is a major issue: Xron seems to be incompatible with ZEO at the moment. The reason why is that the Xron process starts on every ZEO client machine, so everything is executed more than once. I could think of two policies to get around that, both of which should be selectable as an option on a per-event base:
- Xron just runs on one server, e.g. the one that is on the fastest machine; this is useful for cases where you need the events to be executed on the same machine all the time, e.g. if you want to write stuff to the server's local file system
Seems like the most sensible to me. This should be possible to do by splitting the product in two? The Dispatcher and the Scheduler. The Scheduler gets installed on both server and clients but the Dispatcher only gets installed on the server that should run the triggers. I also would like to have a Dispatch monitor ttw where the thread can be start and stopped and the log could be read. Possibly having multiple Dispatcher (for Virtual Hosting situations), which creates another problem because the Dispatcher is started during product instanciation there must be a registry of Dispatchers or someway to start the distributed Dispatcher. For example if the server is restarted. One potential problem would also be notification of failure. I belive I've seen a zLOG email notification product what might be useful.
- Xron runs on all servers (i.e. ZEO clients), but on a first come first serve base, i.e. the server that executes the event first blocks the others from doing so, too.
This would need some kind of inter-process locking, which I think should be provided by ZEO. I'm presently not aware of any such services in ZEO?
Another issue is that Xron will use the current virtual host settings when it executes and reschedules an event. That means that the entries in the Xron Schedule ZCatalog will have different URLs. In some cases the URL that is used to execute an event could be important. E.g., we use Apache with some tricky rewrite rules in front of Zope, and to get around the Apache server the Zope server has to be called from a different URL.
I've noticed that Xcron uses ZPublishers client to trigger events. This seems a bit out-dated to me, wouldn't it be better to use restrictedTraverse? Also all events must be given by it's physicalPath, something we learned the hard way. VirtualPath may be translated to PhysicalPaths when needed, something I think we added to our version of VHM, which we would be happy to share. Who should the events be run as? To day the are run as Anonymous even though there are arguments for passing user name and password I can find any in the UI. I think Event should be run as Owner or ProxyRole. But I'm not sure?
I am willing to help with maintaining Xron, especially the part concerning ZEO, because we really need it ... Joachim
Excellent! :-) Best Regards, Johan Carlsson -- Torped Strategi och Kommunikation AB Johan Carlsson johanc@torped.se Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Visit: Västmannagatan 67, Stockholm, Sweden Phone +46-(0)8-32 31 23 Fax +46-(0)8-32 31 83 Mobil +46-(0)70-558 25 24 http://www.torped.se http://www.easypublisher.com