P2
Any Windows NT Service that embeds a Java VM (using the JNI Invocation API) aborts when the user logs out from Windows. This problem doesn't happen with JDK 1.1. It only happens with JDK 1.2.
Some background:
- It's normal for users to log out from Windows NT servers. When the
user logs out, all of the services keep running. This is what Windows NT
is designed to do.
- Both Microsoft IIS and Netscape Enterprise web servers run as Windows
NT services. If you log out from Windows NT, these keep running.
- ServletExec is implemented as a plug-in for IIS and NES. ServletExec
in turn loads the VM using the JNI Invocation API.
- With JDK 1.1 you can install ServletExec for either IIS or NES, log
out from Windows, and everything works fine.
- With JDK 1.2 if you install ServletExec for either IIS or NES, then
log out from Windows, the web server stops running (NES restarts itself
automatically, but the abnormal termination is logged; IIS doesn't
restart).
This is clearly a JDK 1.2 bug because it doesn't happen with JDK 1.1.
Here are the steps for reproducing it:
1) Download the ServletExec product from the customer web site (www.newatlanta.com) and install it with either the IIS or NES web server on Windows NT.
2) Logout of Windows NT.
The IIS and NES web server will stop running when they shouldn't. At least with the NES web server it will automatically restart itself. No error messages or exceptions are logged when this problem occurs.
sandhya.vora@Eng 1999-07-08
additional info->
Here's some more information that can convince us that this is a bug in the JDK 1.2 Classic VM:
1) When the customer product creates a JDK 1.1.8 VM by loading the following DLL the problem doesn't occur:
C:\jdk1.1.8\bin\javai.dll
2) When the customer product product creates a JDK 1.2 HotSpot VM by loading the following DLL the problem doesn't occur:
C:\jdk1.2.1\jre\bin\hotspot\jvm.dll
3) When the customer product creates a JDK 1.2 Classic VM by loading the following DLL then the problem occurs:
C:\jdk1.2.1\jre\bin\classic\jvm.dll
So there must be a bug in the Classic jvm.dll since that is the only difference in all 3 cases. Whether or not the HotSpot or Classic VM is being used should be transparent to the Java application so this shouldn't be a configuration problem.
The customer uses standard JNI Invocation API calls to create an instance of a VM within their application.
Some background:
- It's normal for users to log out from Windows NT servers. When the
user logs out, all of the services keep running. This is what Windows NT
is designed to do.
- Both Microsoft IIS and Netscape Enterprise web servers run as Windows
NT services. If you log out from Windows NT, these keep running.
- ServletExec is implemented as a plug-in for IIS and NES. ServletExec
in turn loads the VM using the JNI Invocation API.
- With JDK 1.1 you can install ServletExec for either IIS or NES, log
out from Windows, and everything works fine.
- With JDK 1.2 if you install ServletExec for either IIS or NES, then
log out from Windows, the web server stops running (NES restarts itself
automatically, but the abnormal termination is logged; IIS doesn't
restart).
This is clearly a JDK 1.2 bug because it doesn't happen with JDK 1.1.
Here are the steps for reproducing it:
1) Download the ServletExec product from the customer web site (www.newatlanta.com) and install it with either the IIS or NES web server on Windows NT.
2) Logout of Windows NT.
The IIS and NES web server will stop running when they shouldn't. At least with the NES web server it will automatically restart itself. No error messages or exceptions are logged when this problem occurs.
sandhya.vora@Eng 1999-07-08
additional info->
Here's some more information that can convince us that this is a bug in the JDK 1.2 Classic VM:
1) When the customer product creates a JDK 1.1.8 VM by loading the following DLL the problem doesn't occur:
C:\jdk1.1.8\bin\javai.dll
2) When the customer product product creates a JDK 1.2 HotSpot VM by loading the following DLL the problem doesn't occur:
C:\jdk1.2.1\jre\bin\hotspot\jvm.dll
3) When the customer product creates a JDK 1.2 Classic VM by loading the following DLL then the problem occurs:
C:\jdk1.2.1\jre\bin\classic\jvm.dll
So there must be a bug in the Classic jvm.dll since that is the only difference in all 3 cases. Whether or not the HotSpot or Classic VM is being used should be transparent to the Java application so this shouldn't be a configuration problem.
The customer uses standard JNI Invocation API calls to create an instance of a VM within their application.