Best Practices of fault toleration and reliability for scheduled tasks or services

Question

I have been working on many applications which run as windows service or scheduled tasks.

Now, i want to make sure that these applications will be fault tolerant and reliable. For example; i have a service that runs every hour. if the service crashes while its operating or running, i d like the application to run again for the same period (there are several things involved with this including transactions of data processing) , to avoid data loss. moreover, i d like the program to report the error with details. My goal is to avoid data loss and not falling behind for running the program.

I have built a class library that a user can import into a project. Library is supposed to keep information of running instance of the program, ie. program reads and writes information of running interval, running status etc. This data is stored in a database.

I was curious, if there are some best practices to make the scheduled tasks/ windows services fault tolerant and reliable.

Edit : I am talking about independent tasks or services which on different servers. and my goal is to make sure that the service will keep running, report any failures and recover from them.

Emilie

The best advertised I've found is FireDaemon. Not sure how it runs, I'm in the middle of examining it now. But its advertised features are great. – Cohby

Thanks, i did check it out. I d rather code it and have control over it. – Emilie

Answer 1

I'm interested in what other people have to say, but I'll give you a few points that I've stumbled across:

1. Make an event handler for Unhandled Exceptions. This way you can clean up resources, write to a log file, email an administrator, or anything you need to instead of having it crash.

   AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(AppUnhandledExceptionEventHandler);

2. Override any servicebase event handlers you need in the main part of your application. OnStart and OnStop are pretty crucial, but there are many others you can use. http://msdn.microsoft.com/en-us/library/system.serviceprocess.servicebase%28v=VS.71%29.aspx

3. Beware of timers. Windows forms timers won't work right in a service. User System.Threading.Timers or System.Timers.Timer. Best Timer for using in a Windows service

4. If you are updating on a thread, make sure you use a lock() or monitor in key sections to make sure everything is threadsafe.

5. Be careful not to use anything user specific, as a service runs without a specific user context. I noticed some of my SQL connection strings were no longer working for windows authorizations, etc. Also have heard people having trouble with mapped drives.

6. Never make a service with a UI. In fact for Vista and 7 they make it nearly impossible to do anyway. It shouldn't require user interaction, the most you can do is send a message with a WIN32 function. MSDN claims making interactive services is bad practice. http://msdn.microsoft.com/en-us/library/ms683502%28VS.85%29.aspx

7. For debugging purposes, it is way cool to make a service run as a console application until you get it doing what you want it to. Awesome tutorial: http://mycomponent.blogspot.com/2009/04/create-debug-install-windows-service-in.html

Anyway, hope that helps a little, but that is just a couple thing I poked around to find on my own.

Burgundy

Answer 2

Something obvious - don't run all your tasks at the same time. Try to schedule them so only one task is using some expensive resource at any time (if possible). For example, if you need to send out newsletters and some specific notifications, schedule them at different times. If two tasks need to clean up something in the database, let the one run after another.

Also schedule tasks to run outside of normal business hours - at night obviously.

Score

I was talking about independent tasks or services which on different servers. and my goal to make sure that the service will keep running, report any failures and recover from them with minimum or no data loss. – Emilie