[Zope-dev] Xron fragility

[Chris McDonough]

> > Do you think this is this any more effective than having a producer
thread
> > do a lookup every minute to see what jobs are current, after which it
should
> > put the current jobs in a queue?  E.g., as the "run" method of a
separate
> > producer thread:
>
> the same problem applies, a solution might be a timer and a signal
> handler to catch a signal event when a new job is entered into the
> system. events could be managed as some sort of collection of linked
> lists (or whatever ds).

I think this problem is solved by:

- polling for "current" events every 60 seconds *exactly on the 0th second
of the
  minute* (this ensures that stopping and starting the scheduler won't
accidently
  cause a "current" repeating event to fire twice).

- allowing one-time events (which are most likely to need to be executed
immediately)
  to be "current" for the minute implied by the event's timestamp as well as
the minute
  just before that one.  This ensures that an event that has a timestamp
that was "current"
  when entered, but has subsequently been passed due to event polling
overhead
  will be executed (even if it is entered at hh:mm:59.999 or similar).  It
also assumes
  that the scheduling poller will never take more than 60 seconds to poll
all events,
  which is a fairly safe assumption.

- the executor of the event is required to invalidate one-time events once
they've
  been executed (or before they're executed) so they don't get fired twice.

I don't believe there is any need for a signal handler or anything of the
sort, the problem seems to just require careful synchronization.

> i played around with this in a monitor thread and you just can't achieve
> the proper semantics to execute an arbitray zope method. you have to
> recreate the request, response as well as have all the required support
> modules (DTML, tracebacks, etc) to successfully call a method, you are
> in essence reduplicating the publishing machinery. i tried to think of a
> way to get around this but i came up short. you can still access
> variables and simple methods.

This would need to be thought through...  the same problem exists for unit
testing.  :-(

> > I see... would it be naive if I were to say that I think that a
scheduler
> > should fire off threads of its own and not rely on an external facility
to
> > run the jobs?
>
> the dispatcher thread itself has a connection to the ZODB, its using
> client as RPC to invoke the methods on Publishing threads. Since there
> is a hardcoded limit to ZODB connections firing off more connections
> does not seem like a good idea.

AFAIK, threads will block if they can't get a DB connection.  What risks
does that imply?  Is it a problem?