Hi Gary,

Gary Poster wrote:
For our use case, the (quite frequent) cron kick could get to be very, very painful with long running tasks that may overlap (think *lots* of ConflictErrors).

Ah well, if they're doing the same thing, just kicked off frequently, and you're worried about one run not finishing before another, I'd just put in some locking in Stepper that wouldn't run a chain/step if it was already running elsewhere, optionally logging this as an error...

the pain carefully. I'm reasonably confident that Stepper would need to become a long running process with a queue in order to get there.

I don't think it needs to be a long running process, and I think the queue could live elsewhere...

Stepper is currently arguably better if you only have tasks like the ones you list, as long as you only start Stepper at a slow enough frequency that you have no chance for overlap (once a day sounds reasonable, though who knows). If you might overlap, zasync is safer ATM.

The "locking prevents overlap" thing has worked really well for me in the past...

zasync ended up being *very* careful, because we discovered we needed to be. Maybe a simpler, second gen design would need less care.

I tend to prefer logging errors and failing as much as possible. Anything else means Stepper wouldhave to do guesswork and that would be bad...

On the other hand, if you are interested in zasync's through-the- browser use case, maybe Stepper can grow a next-gen through-the-web API also.

Nope, Stepper will never grow that. It's use case is much closer to that of "zopectl run" on steroids, but I think it could work well with a more light-weight zasync...



Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to