>>I have a compiled EXE that serves to produce PDF output from a website. Occassionally it runs into trouble when the parameters sent to it produce a nonsensical query and it hangs or crashes. This leaves an instance running on the webserver that gets in the way of replacing the EXE with a newer version until IIS or even the server box is rebooted. I'm trying to devise a way to cause the EXE to shutdown in the event of an error or if it gets caught in an infinate loop. Thoughts include some type of timer setup and/or a "QUIT" in the catch section of a try/catch sequence.
>>
>>Thoughts or ideas?
>
>My first thought would be to try to cure the disease, not the symptoms. This would mean doing a lot of checking of the input parameters, and only producing a PDF if they pass the checks. If the checks fail, a default/placeholder PDF would be created; if you want to get fancy, that placeholder PDF could list the failed input parameters plus logged message(s) explaining why they were unacceptable.
>
>It's often a good idea to have logging features in routines that are to run unattended and that are expected to be reliable. One technique is to have logging turned on or off via a parameter passed in with each call of the EXE. Again, if you want to get fancy you can pass in a "verbosity level" parameter, and the log-writing calls in your EXE would be run only if their verbosity level is above or below this level. Examining logs can make it a lot easier to catch edge cases when debugging your code.
>
>Handling errors is straightforward. Infinite loops are another story altogether. They are bad news in unattended operation - for one thing, you have to be careful not to have any logging code in a potential infinite loop, otherwise you can fill up a disk or at least saturate its I/O and make the whole server unusable (effectively a denial of service). Of course, the loop may pin one or more CPU cores all by itself even without log I/O calls.
>
>As you suggest, the only way I know to handle an infinite loop is to have a watchdog timer. This means calling your EXE from a launcher; if the EXE doesn't return a return code in a reasonable time, the launcher kills it dead, probably via a WinAPI or similar call. This is ugly, though, it can leave temp files strewn around and could potentially cause memory leaks.
>
>A launcher can also be used to automatically update the EXE:
>

>IF NewEXEInUpdateLocation()
>  CopyEXEFileFromUpdateToProduction()
>
>ENDIF
>
>CallEXE(... )
>...
>

>In general, reliable, unattended code also has to be good code :) You need to code defensively, assuming that pretty much anything you try to do may fail.


Thanks Al. Your thoughts are in line with mine. I do have logging built in and that plus a basic error handler has helped me fix most of the problems. It's just that every once in a while a user finds a new way to break it that I haven't thought of and creates a new problem, or . . . I break it myself by trying to add a new feature or something. I'm basically just looking for a safeguard against problems that haven't been discovered yet.