Windows Azure Guidance – Failure recovery – Part III (Small tweak, great benefits)

re: Windows Azure Guidance – Failure recovery – Part III (Small tweak, great benefits)

Panagiotis Kefalidis — Sun, 16 May 2010 23:17:01 GMT

Oh, I see your point now. You successfully described this as a "pull the plug" scenario. You can't rely on your catch but that's the case on non-cloud solutions too. At any moment a running application can terminate ungracefully, leaving a system in a bad, "dirty" if you want state. I'm not sure if such a scenario exists in Windows Azure. I mean, there is a 30 second notice before shutdown on your instances. A possible hardware failure would probably be forseen before happening, allowing the platform to provide those 30 seconds before switching bringing a new instance to life one some new hardware. If your application is running over the wire, then are some other points of failure too. Then again, having an "always, something can fail" approach is not bad, if properly applied. My concern is how to achieve that thin line between an "overkill" approach which can hurt productivity by being over-cautious to being completely reckless.

Thank you,

Panagiotis

re: Windows Azure Guidance – Failure recovery – Part III (Small tweak, great benefits)

Eugenio Pace - MSFT — Wed, 12 May 2010 18:46:15 GMT

Thanks Panagiotis,

You can keep the try/catch. In a system like this, it is likely the repository is called by many layers of differetn components before returning to the user. So the excpetion at this level will be caught by someone before returning to the user.

The point of the blog post is that you can't rely on your "catch" executing at all. The server might go away before it reaches that point. What do you do then?

The code above leaves the system in a fairly consistent state. At least for a user perspective.

re: Windows Azure Guidance – Failure recovery – Part III (Small tweak, great benefits)

Panagiotis Kefalidis — Wed, 12 May 2010 10:49:54 GMT

Why did you remove the try catch? You can handle the exception and show a user friendly message.

Putting header save in the a nested try catch could help you track which part crashed and show an appropriate error message.

Or is it just that you want to show an exception to the user to warn him that something went wrong, and the "beautification" of your code is left as an excercise for the reader? :)

re: Windows Azure Guidance – Failure recovery – Part III (Small tweak, great benefits)

TM-naiman — Tue, 11 May 2010 15:34:24 GMT

Thank