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
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
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 ...
Torped Strategi och Kommunikation AB
SE-113 36 Stockholm
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
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -