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 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 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 -- 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