[Zope-dev] http://cvs.zope.org/Products/Scheduler vs Xron for cron-like functionality. Advice?

[Johan Carlsson [Torped]]

At 10:30 2002-10-05 +0200, Jean Jordaan wrote:
>>  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,
>
>We have seen the following happen a couple of times: we have Reminders,
>subclassed from XronDTMLMethod. When a Reminder triggers, it sends
>email (using MailHost). When this fails, Xron goes into a spin,
>the Reminder retriggering forever, bloating Data.fs with a Gb or more
>overnight. We've started looking at the code a couple of times, but
>everything looked fine ..

Can't see the reason, yet anyway.

But Client.call of the RPC will always return something correct, even if
the method that is being called fails?

Using Traversal instead, if the call would the Dispatcher would know about=
 it.
A when I should be able to stop the event from triggering, and potentially=
 send
an e-mail to the admin (which must not fail ;-).

I'm trying replacing RPC with restrictedTraverse right now.

I'm not sure if I have a security manage in the context of Dispatcher.
But it works.


Some thoughts:

Now it seems like XcronMethods rely on REQUEST to change timer,
because it needs it to be able to override for ZClasses.
I don't have a REQUEST object, because I'm calling from
the Dispatcher thread.

This is how I think I'm gone solve it.
Split trigger in two separate methods: trigger and reschedule.
This also means if trigger raises an exception, reschedule will not be=
 called
preventing trigger from being called and fail again.

It will still be allowed to override trigger, but reschedule will not be=20
allowed.

I think there should be a very narrow bit of code that actually can change
the settings of an event. I got a felling there maybe potential security and
stability problems here. And I'm very concerned about the ZCatalog being
safe here. Is it possible to spoof a catalogObject call from un-secure=20
ttw-code?

Also I'm think the trigger time should be changed to a start time and a
recurrent setting. The next event should always be calculated from these
setting, never be written. Which mean an event could be a read only
operation, avoiding unnecessary ZODB bloating.

The recurrent setting should be iCal compatible to be able to use
Xron for managing triggers in a future Calender server, but this is
current not a prioritized feature for me. I think it will happen though
in the future.

Also, a bit of a contradiction to the read-only events above, I think
there is allot of unnecessary blather to the zLOG. I would rather
let the Event keep an history over not critical events.
It could be optional, I still want the Event to keep a volatile history log
to prevent it from being called several times for the same occurrence.
This wouldn't be perfect because volatile attributes are thread specific
but it could prevent the object from going stall.


Best Regards,
Johan Carlsson


--=20
Torped Strategi och Kommunikation AB
Johan Carlsson
johanc@torped.se

Mail:
Birkagatan 9
SE-113 36  Stockholm
Sweden

Visit:
V=E4stmannagatan 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