Changing NT Service Options

When you install Tomcat as a service, it’s set to start automatically, which means that if you were to restart the computer, Tomcat would start automatically. From now on, every time Windows is started, Tomcat will automatically start up at boot time and will be available then.

You can further customize the service by choosing the Properties option from the context menu. This allows you to change the startup type to manual or entirely disable the service, plus it allows you to choose to automatically restart the service should it crash. This last option is especially useful as it also allows you to run a script should the server fail. You also have the option to reboot the computer. (However, you should consider seriously what you put in this script because it can offer a security hole if the script does something that may be used as a denial-of-service attack.)

It also allows you to carry out different actions depending on how many times it has failed (by choosing the Recovery tab), so you can initially request a reboot of the service and then request a reboot of the machine. Then, any subsequent failures will cause a script to run that perhaps alerts you of the failure.

The only possible reason for restarting the machine is if the applications that are running on Tomcat depend on an ordered bootup and no loss of connections between the applications and their various resources. This means that, on the whole, writing a script that flashes a warning or similar is more desirable than rebooting the system.

If you want to set the recovery options, right-click the Tomcat service entry in the list and choose Properties. In the window that opens, choose Recovery, and you’ll see the options shown in Figure 4-3.

Figure 4-3: The Tomcat service’s recovery options

The default is for no action to be taken. You’re going to change this behavior and restart the server a maximum of twice and then run a script on the third and subsequent failures. Select the First Failure drop-down box, and choose Restart the Service. Do the same for the second box. Set the time after the crash that the service should be restarted to one minute. This should give any external resources enough time to notice the failure and respond if necessary.

If this is a stable server that rarely fails, set the reset level high, say, to 20 days, which should mean that consistent failures are noticed and addressed. It may be that it fails only occasionally— you want to know nevertheless. Setting the reset level high maximizes the chance that the third option will run, thus alerting you to the problem. Remember that the script can easily be responsible for restarting the server so that users feel a minimal downtime, yet you’re still notified. In fact, this option may be preferable to having the system automatically restart the server without explicit notification of problems.

If the server fails often, it may be necessary to turn the reset level down so that failures can be noticed.

Now choose Run a File from the Subsequent Failures option menu. This will enable the Run File menu where you can choose the file to run (normally a batch file). The fail count is passed to the file as a command-line parameter for the script to report.

For the moment, assuming that you haven’t specified any other command-line prompts, you can discover the failure count using a file such as the following:

 @echo off  if NOT %1==/fail goto end  echo Number of failures to date is %2 >> T4.fail  :end  cd "c:\jakarta-tomcat\bin\"  start startup 

The previous file is the simplest possible reporting script that merely appends the failure count to a file named T4.fail each time a failure occurs before restarting the server (but not as a service, rather as a manual start in a new command prompt window). In the first line you turn off echo, the second line checks that the first command-line argument (%1) is equal to /fail and if so prints the following line:

 Number of failures to date is %x% 

where x is the number of failures. Notice that >> T4.fail makes sure that echo is added to the T4.fail file and that the output is appended to, rather than replaces, the existing contents of the file. A single > would replace the file contents.

The result of multiple failures with this file, as set previously to run on the third failure, would be something along the lines of this:

 Number of failures to date is %3%  Number of failures to date is %4%  Number of failures to date is %5%  Number of failures to date is %6% 

Alternatively, you can run a Java class that extracts the information and perhaps e-mails the failure to you. To do this, simply forward the fail count to your program, calling it as follows:

 @echo off  if NOT %1==/fail goto end  java ReportTomcatFailure %2  :end  cd "c:\jakarta-tomcat\bin\"  start startup 

The number of failures is now available as ReportTomcatFailure’s first command-line argument (accessible as args[0]).

In addition to the security risk involved in having the computer automatically reboot itself, it’s not entirely necessary. Since Tomcat runs within a JVM, unless you’re doing something unusual, a failure of the Tomcat instance is isolated from the rest of the system and a soft reboot should suffice for most problems. This puts hardware reboots in the very serious category, and, as such, they’re something you probably want to control manually.