Building a failsafe application

I have a program called a "Sentinel" running permanently on a network. The sentinel needs to perform various different tasks (file copy, read/write data to/from mySQL, ftp files etc) at different intervals.

The Sentinel uses a standard timer component to provide triggers for the various tasks and under normal conditions it works fine. However, my client wants an assurance that the sentinel is bullet-proof and will continue to run under all circumstances including:

Machine reboot
Connection failure to mySQL
Anything else that can go wrong...

The software is still being tested and I plan to convert it into a Service Application once the testing is complete. That way I can set it to start automatically after a re-boot.

My question is: am I going about this in the right way: If Yes, do I just have to make sure that all exceptions are trapped. If No, has anyone got any suggestions as to how else this should work?

Thank you.
WeeStinkerAsked:
Who is Participating?
 
SteveBayConnect With a Mentor Commented:
Whoa& you guy are mean, picking on poor little ole MS. You know their trying as hard as they can:P
Per previous posts -You cannot guarantee that an application will not fail in some unexpected way.
One thing you can do is provide an alert when it is down. What I have done is to have my Service Application write to a DateTime Field in the DB once per loop or x number of loops etc. Then I have a service that runs on a client or a number of clients the checks the value of that field. If the value is too old then you can popup a message that tells your user(s) that the service has not reported recently. The user then can look at logs and/or stop and restart the service which frequently solves the problem. I find this to be better than a customer being pissed at you for not creating a perfect application.
0
 
Geert GConnect With a Mentor Oracle dbaCommented:
so after testing you will create a new application ?
and then deploy it untested ?

my 2 cents:
convert it to a service application first and have it tested then !

why ?
the testers will look innocent if they missed something,
because you actually delivered a totally different application.

Main difference:
A service application doesn't have a GUI.

Otherwise:
Testing should involve User Access rights for file shares / copying etc
as you can set the service app to run with a different user.
If the DB is down, not much you can do, except wait for it's return.
Trying to reconnect sometimes proves a pain in the a s s too.
Executing stored proc and getting a failure is sometimes a difficult one to solve, unless everything is in a transaction.
Anything else that can go wrong ?
um, probably
I use threads to keep all stuff like this nice and smooth,
but now and then i get a thread hanging.
One thing that we haven't figured out yet.
Printing: The printer just doesn't respond sometimes, not even with an error.
So that thread just waits indefinately.

Bullet proof ?
That's easy, it is !
Ask the client to shoot your software and see if it still runs.
Remind him it can't run if the machine is not running ... :)







0
 
mikelittlewoodConnect With a Mentor Commented:
My 2 cents.
You can do as much error handling and checking you want, but even the best applications crash now and then. You only need to take a look at microsoft for that.
0
 
Geert GOracle dbaCommented:
ow, thats even better, it's probably running on a Microsoft OS.
With monthly or bimonthly automatic updates !!!

Make note to client:
App will be just as failsafe as the OS your running on !
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.