[Twisted-Python] service takedown (one newbie to other newbies, methinks)
Bill la Forge
laforge49 at yahoo.co.in
Fri May 21 22:07:54 EDT 2004
You hit the nail square on on both points.
1. Things happen. In reviewing bsddb, I find that its gennerally
recommended to run recover as part of the startup process.
This makes clean shutdowns a bit less critical. But still, I'm
thinking it should be attempted.
2. Sometimes services need to be shut down without taking down
Twisted. This is especially important if Twisted is also going to
provide an administration interface, as some administration activities
may be easier when the base service is off-line.
3. Support of non-critical service failure? A service may sometimes be
critical and othertimes not. Sounds like a configuration issue that
would be nice to standardize at some point. But perhaps the best
solution would be to leave it up to something else, perhaps a service
monitor service, which can decide when its not worth keeping Twisted
running, or perhaps putting it into a "I'm dead except for administration
One conclusion here is that perhaps a service should never say die
(er, stop). Its always better to separate a smart service from the smarts
needed to manage that service--a service should rarely be coupled to the
Glyph Lefkowitz <glyph at divmod.com> wrote:
On Fri, 2004-05-21 at 20:47, Bill la Forge wrote:
> If I write a generic service, even a MultiService, for use in multiple
> applications (as is my intent), then there is still a possibility that
> some other service, specific to a particular application, or an
> generic service, may fail to initialize. So the need to capture the
> shutdown event remins.
I appreciate your questions on these shutdown issues, since I think we
do still have a few semantic issues to nail down regarding startup and
shutdown. However, I do think it's worth mentioning that you should
never depend too heavily on shutdown code if you are interested in
reliability: servers do crash, and machines do lose power, so a "clean"
shutdown should always be a convenience and not a necessity.
(A more serious issue that we need to address is making sure that you
can _attempt_ to bring up a new service inside an already running
reactor, fail to bring it up, and not interrupt existing,
already-running services or alter their state in some way; or, that you
can bring it up and bring it down with the same results.)
Twisted-Python mailing list
Twisted-Python at twistedmatrix.com
Bill la Forge
Yahoo! India Matrimony: Find your partner online.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-Python