| Hi Peter, I think you and I see different customer use cases. As I mentioned at the last OSGi f2f, we have customers whose applications take a significant amount of time to start and they have many instance. Rolling updates can therefore take a long time if full application restart is necessary, so these customers want to minimise application update time and disruption. These are transactional deployments with failover so they can be recovered if someone trips over the power chord, but that doesn't mean they want use this during normal maintenance. Regards, Graham. Graham Charters PhD CEng MBCS PhD STSM, WebSphere OSGi Applications & Liberty Repository Lead Architect, Master Inventor IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21 2JN, UK Tel: +44 1962 816527 Email: [email protected] Peter Kriens --- Re: [osgi-dev] How to cleanly update/uninstall bundles ---
I am not sure I agree with your conclusion. :-) Since it is theoretically impossible to protect against hard failure (power, kernel panic, kill -9, distributed call when the cable is plugged, etc) any valuable application must have protection against an unexpected exit at any moment in time. Idempotency, consensus, and transactionality are your friends in these cases. So if you are protected against these bad failures, how bad can an in-flight shutdown be? Best case you can shorten the recovery time at restart but this often requires additional complexity that can then also fail. Since the chance that things go wrong in-flight is quite small I would take the recovery cost in the unlikely event you got caught. Related is my very old opposition to an update or uninstall callback to the bundle. Though it is an awfully attractive idea with lots of good stuff the party is spoiled because you cannot guarantee such a call circumstances. Billy Joy (Sun Founder) once told us a story about the development of the Internet, of which he took part. Initially they tried to make every router perfect but this turned the routers incredibly expensive and there were still failure scenarios that even a perfect router could not handle (power, cable cuts). Then someone proposed to assume the routers were very imperfect and that the end points should correct the problems in the net. This changed a very large number of very hard to handle failure scenario into one problem: how to handle a missing package. If a router panicked, lost power, a cable was cost, too busy, out of memory, had no clue: discard the package. It is a pervasive problem in Enterprise software world that we want to ignore failure because it is so hard. For example, Blueprint has this awful service damping that looks so attractive for the developer (Look Ma, no dynamics!) but by hiding the reality you get caught in lots of unexpected places. Bad software expects an unchanging perfect world, good software is more realistic. Embrace failure! :-) Kind regards, Peter Kriens
|
