[Web-SIG] Web Site Process Bus

[Robert Brewer]

Phillip J. Eby wrote:
> At 02:17 PM 6/25/2007 -0700, Robert Brewer wrote:
> > Phillip J. Eby wrote:
> > > At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote:
> > > For example, if an error occurs, isn't that an indication that the
> > > component is broken?  Masking the failure just makes it 
> > > less likely the component will get fixed in a timely manner.
> >
> > Yes, the component is broken. However, at runtime, breakage in a
> > CherryPy component shouldn't keep a Quixote component from, say,
> > correctly freeing its DB connections.
> 
> In theory that makes sense, but in practice if you're using 
> priorities because there is a dependency sequence involved, then you 
> now have a new problem, since a component you're relying on having 
> started or stopped first, is now violating its invariants.
> 
> I'm not opposed to logging or catching errors, but I am opposed (in 
> the absence of more specific evidence) to allowing callbacks to 
> propagate unhandled exceptions in the spec, or encouraging event 
> senders to make heroic efforts in the face of unhandled 
> exceptions.  Trying to recover from brokenness is generally not very 
> likely to result in *less* breaking, IMO.

I agree with that in the general case, and specifically for site
startup, which is prone to dependencies and priorities. The specific
case where I feel we need different behavior is when trying to shut down
a site, which rarely involves dependencies and priorities, but can often
lead to increasing damage if an early component errors and remaining
resource cleanup routines are not allowed to run. Maybe we should just
special-case the latter and let the rest fail fast.

> > > Meanwhile, if you get a start call, you must be starting, 
> > > right?  So why worry about the state?  It'd be simpler to
> > > just use "before/during/after" messages the way Twisted does.
> > > Your "block" example could be replaced by waiting for the "after" 
> > > message of the desired state, for example.
> >
> > That's a possible way to go. My intention was to support both
> > 1) examination of the state by external components (for
> > operations other than 'block'--progress meters spring to mind)
> > and 2) restrict some state transitions if necessary; for example,
> > make bus.start() do nothing (or block) unless the state is
"STOPPED".
> 
> Progress meters can be handled by callbacks, too.

With sufficent complexity, yes.

> As for the restrictions, who benefits?  ISTM that components need
> to manage their own lifecycles anyway and should be idempotent
> with respect to repeated transitions.

Good point. Requiring idempotent operations would allow fun sequences
like:

>>> bus.exit()
>>> bus.exit()
>>> help!
SyntaxError: invalid syntax
>>> os.unlink(errant_lock_file)
>>> bus.exit()
...process finally exits...

That would also allow someone to call bus.exit() in the middle of
another thread executing bus.start()...if each component manages its own
state, that would minimize shutdown errors like closing DB connections
that were never opened.

Hmm...


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org