This is the same bug as described in bug-id: 4323062 except that on installing
Hotspot 2.0, the VM dies completely when the user logs out from Windows.
There is no thread dump on Java console on logout as the Javaconsole
dies along with the VM. The VM process dies out when the user logs 
out from Windows.

The problem description is essentially the same as in bug: 4323062.
This problem does not happen when Hoptspot is not installed.
On the contrary, we see a thread dump on the java console 
and the clients can make connection. 

With Hotspot installed, the problem is also seen 
with the workaround documented in bug: 4323062.

This problem does not occur on JDK 1.1.x and is seen on JDK 1.2
and greater versions.

The problem appears to be as a result of the signals (like ctrl + break) 
accepted by the child process in JDK 1.2 from the parent proces.

----
Follow these instructions to reproduce the problems:

Please install Hotspot 2.0 before starting the test.

INSTRUCTIONS FOR INSTALLING SERVICE ON WINDOW NT 4.0
==============================================================

1. Extract the contents of the zip file to say C:\
2. Assuming this, you would now have a directory C:\testntsvc
3. Create an "System Variable" TEST_ROOT in Environment tab of the System
   Properties from the "Control Panel" Settings and set C:\testntsvc to
   TEST_ROOT.
4. Append C:\testntsvc to your classpath settings in control panel and also 
   make sure your CLASSPATH is a "System Variable". 
5. Go to DOS command prompt and go to the directory c:\testntsvc
6. Type TestNTSvc -install to install the NTService.
7. Now go to your control panel settings and click on the "Services"
   icon to see if the NT Service "TestNTSvc" is installed.
8. If it has not been installed please let us know.
9. If it has been installed, then select the "TestNTSvc"
in the services window, click on the button "Startup" and set
the "StartUp Type" to Manual(from Automatic). 
Also check the checkbox for "Allow Service to interact with the Desktop".
10. Now  click on OK Button and close the control panel settings.
11. Now ensure that you have installed  Java2 on your 
	NT Workstation.
12. Open the file "cmdscripts.cfg" file in C:\testntsvc, and update your
directory path for the various jre vms. You can comment all the lines
except the line which you intend to invoke a particular JVM, so for example
you intend to run jre1.2.2, then the following would be the text in the
file cmdscripts.cfg file:

================================================================================
adm=d:/jdk1.2.2/jre/bin/java -mx256m -DTEST_ROOT=%TEST_ROOT% testserver
#adm=f:/jdk1.1.7b/bin/java -mx256m -classpath %classpath%;f:/testntsvc -DTEST_ROOT=%TEST_ROOT% testserver
#adm=f:/jdk1.1.7b/bin/jre -mx256m -cp f:/testntsvc -DTEST_ROOT=%TEST_ROOT% testserver
adm=f:/jdk1.1.6/bin/jre -cp f:/testntsvc -DTEST_ROOT=%TEST_ROOT% testserver
#adm=f:/jdk1.1.6/bin/java -classpath %classpath%;f:/testntsvc -DTEST_ROOT=%TEST_ROOT% testserver
================================================================================
13. Save the file and close it.
14. Reboot your workstation so that the classpath and the new "System
variables" comes into effect.
15. After booting go to the control panel.
16. Go to the services panel in control panel and
start the NT Service "TestNTSvc". You should now see the Java console
for d:/jdk1.2.2/bin/jre with the statement "wait" being printed
in the console.

17. From a client, try telnet server's-ip-address port-number like
    telnet 129.144.144.242 7080

18. The telnet works  normally after printing the statements on the client console. (We tried on windows clients as well as on solaris clients)

telnet 129.144.144.242 7080
Trying 129.144.144.242...
Connected to 129.144.144.242.
Escape character is '^]'.
accepted

19. Now try logging off the NT Workstation and you will see the JVM process
    dies along with the Javaconsole and the telnet session fails
    when you log back in.

telnet 129.144.144.242 7080
Trying 129.144.144.242...
telnet: Unable to connect to remote host: Connection refused

20) If we un-install Hotspot, on windows logout, we see that the JVM dumps a 
Java thread trace and the telnet sessions works normally when you log back in.

telnet 129.144.144.242 7080
Trying 129.144.144.242...
Connected to 129.144.144.242.
Escape character is '^]'.
accepted

N/A

In JDK1.1.x and JDK1.2.2, CTRL_LOGOFF signal is handled by windows default
console control handler, it allows a console application (launchs from NT
services) to countinue running when a user logs off the system and log back in.

In Hotspot 2.0, a new console control handler was installed (os_win32.cpp), it
raises SIGTERM to terminate the console application when received CTRL_LOGOFF
signal. The same is true with JDK1.3.

  xxxxx@xxxxx   2000-08-16

-------------------------------------------------------------------

Please see the evaluation for 4323062, which contains a complete analysis
of the problem as well as a solution. Pending contact with the customer,
this bug will be closed as a duplicate of 4323062.

  xxxxx@xxxxx   2000-08-30


-------------------------------------------------------------------


Sender:   xxxxx@xxxxx  

Subject: Re: BugId 4358808 : (P2/S2) Has been Updated - by lewy   Escalated Bug.
Date: Fri, 20 Oct 2000 17:09:20 -0700

Lew:

To let you know, we are still working on 4323062 and some related bugs. We
will have a cross-platform update available within a week or two.

-Ken Russell

JVMI2 - The Java/NT Services Utility NT4/2000 Version 2 - April 14, 2001
Available at http://www.kcmultimedia.com/jvmi/

JVMI2 provides everything needed for running pure Java applications as NT services. 
In addition to its original role as a simple alternative to java.exe for trapping 
logoff events with JDK 1.3.0, it provides a great deal of new functionality. 

1) Command line installation or removal of your Java applications as NT services 
2) Easy configuration of service and display names, working directory, redirection of
   System.out and System.err to a log file, service dependencies and arguments to
   the JVM and your application, using XML formatted text files. 
3) Automatically traps logoff events if using JDK 1.3.0 
4) Provides a simple mechanism for pure Java applications to receive stop events
   from NT by implementing the provided SCMEventManager Java code. 
5) Improved event-logging and error reporting to assist in debugging troublesome
   installations. 

Try running it on JDK 1.3.1 - beta you'll find it works. 
However, if you run it on JDK 1.3.1 - b24 (release) it does 
not. :-(

It works with JDK 1.3.1 using the -Xrs option --- reducing 
the mesagges from the OS

/kjetilhp