[Twisted-Python] Re: ApplicationService orderization
bob at redivi.com
Wed Apr 9 18:36:03 EDT 2003
I don't have time for a large reply right now, but....
On Wednesday, Apr 9, 2003, at 17:30 America/New_York, Kevin Turner
> [Recap: Last night, Bob was complaining that the order that services
> were started and stopped was undefined, saying
> Bob> well if you have service A dependent on service B
> Bob> and you don't want service A to actually start service B
> Bob> like let's say you have a database service or something
> Bob> and you have another service that wants to persist stuff using the
> Bob> database service
> so he made the order in which services are started defined as the order
> in which they were added to the service collection, and the reverse for
> Bob, I fear this solution is too fragile if your services really depend
> on one another. While it will work for now when installing services is
> something that happens once in mktap, I fear it'll break down with more
> dynamic service management. Example::
> application.addService("dataStore", StupidStorage())
> application.addService("dataMaker", FooService())
> # ...later, decide we have outgrown StupidStorage:
> application.addService("dataStore", RealStorage())
Well nomatter what, unless it uses
application.getServiceNamed("dataStore") everywhere, you just broke
dataMaker. If you're changing the storage you have bigger things to
worry about than this little corner case. You need to pause/stop
FooService, export all the data from the existing storage, stop the
existing storage, start the new storage, import all the data into the
new storage, change FooService's reference to the new storage,
resume/start FooService, and cross your fingers.
It is a good feature that services get started and stopped in a
sensible order, there's no reason they shouldn't. I didn't want to
change the implementation to a list because that would've required more
code to change, and had the capability to break existing stuff because
there is no API iterate an AbstractServiceCollection (or the bastard
Application class, which should be one but doesn't mixin IIRC).
> With your ordering, the new dataStore will now stop before dataMaker
> Instead of introducing ordering dependencies into the flat top-level
> service namespace, I think the right answer to your problem is to do as
> Chris suggested: Use a hierarchical structure by making dataStore a
> MultiService, and adding any dataMaker services at its children. That
> way your dataStore can always make sure its children shut down before
That's only an issue if you use persisted Application objects, I don't.
What if you want to stop the storage without stopping it's children?
In some cases, my ApplicationServices only depend on the storage for
initialization anyways, so it wouldn't make sense to force them to shut
down when the storage does.
> Does this work for you? If so, I would like to revert your changes
> making Application.services an OrderedDict before the (imminent!)
> release, just because anything that requires a change to the
> persistnceVersion is a big potential spot for trouble. We have no
> inter-version testing framework at all.
You can take out the version upgrade if it doesn't work. I used an
OrderedDict for that reason, it has the same interface as a normal
dict.. so no change to the code (other than stopping in reverse order
of keys, which will still work on a regular dict, and __init__ of
course) were made. The upgrade was purely so new services added to old
application objects would have their start/stop order preserved.
More information about the Twisted-Python