From erik.van-der-goot@jrc.it Wed Aug 6 14:32:07 2003 Return-Path: Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 49374 invoked from network); 6 Aug 2003 14:32:07 -0000 Received: from mrelay.jrc.it (139.191.1.65) by daedalus.apache.org with SMTP; 6 Aug 2003 14:32:07 -0000 Received: from mrelay.jrc.it (localhost [127.0.0.1]) by mrelay.jrc.it (LMC56C2B) with ESMTP id h76EW7305521 for ; Wed, 6 Aug 2003 16:32:07 +0200 (MEST) Received: from isis-ms.sti.jrc.it (isis-gs.sti.jrc.it [139.191.8.244]) by mrelay.jrc.it (LMC56C2A) with ESMTP id h76EW7u05517 for ; Wed, 6 Aug 2003 16:32:07 +0200 (MEST) Received: from ikaro2.jrc.it ([139.191.246.234]) by isis-ms.sti.jrc.it (Netscape Messaging Server 4.15 gs Mar 21 2002 15:13:49) with ESMTP id HJ7CDE00.1KP for ; Wed, 6 Aug 2003 16:32:02 +0200 Message-Id: <5.2.1.1.2.20030806155638.02d24588@isis-ms.jrc.it> X-Sender: gooteri@isis-ms.jrc.it X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 06 Aug 2003 16:18:23 +0200 To: tomcat-user@jakarta.apache.org From: "Erik Van der Goot" Subject: Tomcat as an NT Service Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N We have just made a small mod to the javaservice.exe program (see also http://www.alexandriasc.com) , known to most of you as tomcat.exe from the tomcat bin directory. If you are interested, please get in touch with erik.van-der-goot@jrc.it or ken.blackler@jrc.it. The reason for the change is that we wanted to use the Win2000 Server service recovery feature in some cases in order to keep the system alive even when there is a problem. One case in point is a java.lang.OutOfMemory error which is definitely and demonstrably dodgy, probably due to a garbage collecting problem. (Honest). In the original software a System.exit(i) would indeed cause the service to terminate, but always gracefully, i.e. the service was always reported as STOPPED to the Service Control Manager. Since this is not a failure, the service recovery does not come into action. In order to be able to force the service recovery we modified the code to take different actions on different JVM exit codes. A code of 0 is as per usual. No extra error messages, service stops. An exit code > 0 a service specific error message is logged in the application log, but the service stops normally. An exit code < 0 is considered as a serious fail and will register a service specific message, and FAIL the service. This means that the Service Recovery will come into action. A minute later your system can be up and running again. Note that there is a registry key which determines the system behaviour after service failure: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug Auto = 0 Prompt user with debug window BEFORE terminating the process (and therefore before allowing the service to restart). REQUIRES USER INPUT!!!!: Auto = 1 (server default) Don't prompt user with debug window, create dump file and then end the process, therefore allowing the service to restart" Erik