Para quem perguntou sobre serviços no NT.
Tive muiiiiiiiitos problemas pra consegui fazer as coisas funcionarem.
Bug Id 4323062
Votes 587
Synopsis Any Windows NT Service embedding Java VM aborts, when user
logs out from Windows
Category java:runtime
Reported Against kestrel-rc2, kestrel-rc1, kestrel-rc3, 1.2.2, 1.3
Release Fixed
State In progress, bug
Related Bugs 4358808
<http://developer.java.sun.com/developer/bugParade/bugs/4358808.html>
Submit Date Mar 17, 2000
Description
IHAC with a NT Service program which starts a Java program. The java
program is a simple program with a server socket waiting to accept socket
connections. The program is installed and everything works fine until the
user
decides to log off. Since the Java program is installed through the NT
Service,
the program should continue to work even when the user logs out of the
system. But on the contrary, the program goes into an unstable state and
the
program hangs. I have enclosed the stack trace which I managed to capture
by
making the NT Service interact with the desktop, so we get to see the
console.
This problem does not occur with JDK1.1.x. This happens only for JDK1.2 and
greater versions. The Java thread dump and testcase TestNTSvc.tar.Z is
in the attachments.
Follow these instructions to reproduce the problems:
SOURCE MODIFICATION
1)In the clienttest.java file edit line 16:
s = new Socket("sworks.eng.sun.com",7990);
with your test system's host address. Save and recompile.
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 contact me at xxxxx@xxxxx
or 650 526 3336.
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 JDK1.1.6, JDK1.1.7b and 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 "Getting Connected" being printed
in the console.
17. Run the Java test program testclient.java on the command prompt,
by typing in at the command prompt c:\testntsvc>java testclient
18. The program works and exits normally after printing the statements
"Creating a Socket", "Created the client Socket" on the console. This
is what a remote client system would see when accessing the Server service.
19. Now try logging off the NT Workstation and you will see in the Java
console
that the JVM dumps a Java thread trace and the service hangs
unresponsive
when you log back in.
java version "1.3.0rc2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc2-Y)
Java HotSpot(TM) Client VM (build 1.3.0rc2-Y, mixed mode)
I'm writing NT-service by JDK1.3 (and some C codes).
1.NT-service start by manual. (check "System Account")
2.logoff
...then, NT-service(running JVM in service) stop process.
I hope, cancel shutdown JVM.
(Review ID: 103003)
java version "1.3.0rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc1-T)
Java HotSpot(TM) Client VM (build 1.3.0rc1-S, mixed mode)
Using ServiceInstaller 1.1 (http://www.kcmultimedia.com/smaster) install a
simple Java app as a service that outputs some trivial data to a file every
10 seconds.
Here's the simple demo service:
import java.io.*;
import java.util.*;
public class Test2
{
public static void main(String[] args)
{
Date now;
PrintWriter out;
try{
while(true){
now = new Date();
out = new PrintWriter(new FileWriter("test2.out",true),
true);
out.println(now.toString());
out.close();
Thread.sleep(10000);
}
}catch(Exception e){
System.out.println(e.toString());
}
}
}
Start the service from the Control Panel|Services Applet, and check the
contents of the file test2.out, which should append a line showing the
date and time each 10 sec.
Log off, and log back in.
Although NT thinks the service is still running, it is not. You will see
that lines are no longer appended to the file.
This seems to only occur with JDK 1.3 RC1. Under JDK 1.2.2, the test app
keeps running thru the login/logout
(Review ID: 102993)
webbug bgiel nostromog
Workaround
The workaround is to create a new thread in the parent process to read the
pipe.
In this way, the pipe between the parent and child process will not get
overflowed. The application will not hang any more. Also if the return value
from read is -1, the read thread may be dismissed to retain resources.
xxxxx@xxxxx 2000-06-02
Evaluation
It seems that this is not a bug.
In 1.1.x, runtime.exec create a new process which is a detached process, so
the
child process will not accept signals (like ctrl+break) from the console of
the
parent process. That's why in 1.1.x, there's no thread dump.
In 1.2.2, runtime.exec create a new attached process, the child process can
still accept the signal from the console of the parent process, it's stderr
is
linked to the parent's pipe. After it received the signal, it sent out
thread
dump to stderr which redirects to the pipe, as the pipe has a limited
capacity,
another thread needs to read from the pipe to keep it going, otherwise,
the child process appears hang.
xxxxx@xxxxx 2000-04-18
------------------------------------------------------------
The evaluation above is incorrect; a corrected one follows. A solution
exists for this problem; please see the end of this evaluation for it.
The problem was caused by the addition of the shutdown hook mechanism
to 1.3. Shutdown hooks, compared to the System.runFinalizersOnExit()
mechanism, have stronger guarantees regarding when they are run; for
example, if the VM is terminated by a Ctrl-C, finalizers will not be
executed via runFinalizersOnExit, but shutdown hooks will be run.
On Win32, shutdown hooks are implemented by adding a console control
handler (see the documentation for SetConsoleCtrlHandler) which, upon
seeing a condition like a Control-C or a "user logoff event", raises
the termination condition in the VM. This causes the shutdown hooks to
be run.
Both the shutdown hook mechanism and the Ctrl-Break stack dump require
signal-like information. 1.2 implemented the Ctrl-Break stack dump
using the POSIX "signal" call on Win32. It turns out (as was noted in
the 1.3 VM code by xxxxx@xxxxx that this mechanism translates all
console events except Ctrl-C into SIGBREAK, which is not sufficient
granularity to support both Ctrl-Break and shutdown hooks. This is why
the console control handler was added in 1.3.
When the VM's console handler receives the CTRL_LOGOFF_EVENT, it
informs the rest of the VM of pending termination (thereby causing
shutdown hooks to be run) and returns TRUE. According to the MSDN
documentation, a return value of TRUE for this event will cause the
popup window for process termination to be displayed. It seems that
this return value was chosen because the VM is still doing work
(running the shutdown hooks asynchronously) after the
CTRL_LOGOFF_EVENT is received, and the author thought that returning
false would cause the VM to be terminated by the OS while doing this
work (as is stated in the MSDN documentation: the system's default
handler terminates the process).
The MSDN documentation is not specific about the relationship between
services and the CTRL_LOGOFF_EVENT. Conceptually, a service runs in
the background and should not be associated with any particular user's
login session, so one might expect that a service should not be
notified of logoff events. However, Win32 does send these events to
services. Interestingly, the default console handler for services
differs from the default for ordinary console processes; services
continue to run after their default handler executes. This is what
allows ordinary programs (which either do not install a console
handler, or which return FALSE in their console handler for
CTRL_LOGOFF_EVENT) to work with, for example, ServiceInstaller.
However, it does not seem that there is a way for a process to query
whether it is running as a service. If there were, the correct
behavior for the VM upon receiving the CTRL_LOGOFF_EVENT if it were
running as a service would be to skip running the shutdown hooks, not
signal the termination condition to the rest of the VM, and return
FALSE. Otherwise, the two possible workarounds are either to provide
another command line option to java.exe ("running as a service on
Windows NT") or to somehow intercept the CTRL_LOGOFF_EVENTs at the
service wrapper level.
--
Since the time this bug was filed, its original submitter (who is the
author of ServiceInstaller) has released a revised piece of software,
called JavaServ, which solves this problem elegantly by using the JNI
Invocation API to create a Java VM and installing a console control
handler afterwards which intercepts the CTRL_LOGOFF_EVENT and prevents
it from being passed to the VM. It also contains other useful features
like allowing pure Java programs to receive service control events.
JavaServ may be downloaded from
http://www.kcmultimedia.com/javaserv/
The comments on the JDC also contain the source code to a similar
program.
xxxxx@xxxxx 2000-08-30
Your Comments & Work-arounds
(These are NOT written by Sun!)
Include a link with my name & email
Wed Apr 12 04:02:54 PDT 2000
jsommer <mailto:[EMAIL PROTECTED]>
This is a HotSpot problem, not a jdk 1.3 problem - the
problem also occurs with HotSpot-2.0/jdk 1.2.2
Fri Apr 21 00:29:58 PDT 2000
gageot <mailto:[EMAIL PROTECTED]>
Not a bug ?????
So how do you have a Java server application on NT ?
Fri Apr 21 11:27:23 PDT 2000
javageorge <mailto:[EMAIL PROTECTED]>
This is a bug!! I can run my Java application as an NT
Service using JDK 1.2.2, but can NOT run it with JDK 1.3
RC3. Nor can I get it to work when running with Java
HotSpot, regardless of which VM I use. My only solution is
to run with JDK 1.2.2 without Hotspot ( too slow.... ).
I have downloaded several programs that create NT Services
for Java apps, and see the this same behavior, regardless of
which one I use. I also see this behavior when I create the
NT Service using Microsoft's srvany.exe.
You would think it would be in Sun's best interest to make
it VERY easy to create an NT Service for a Java Application.
Don't they want Java Applications to proliferate on NT?? I
had hoped that Sun would have provided such a tool, but this
is not the case...
Instead, here's the tools I've tried in addition to srvany:
http://www.kcmultimedia.com/smaster/
http://www.formida.com.au/firedaemon
This has been a major headache for us and I really hope this
is fixed before JDK 1.3 is officially released!!
Thu May 04 02:06:23 PDT 2000
nostromog <mailto:[EMAIL PROTECTED]>
It keeps going on with rc3. Using Mike Jennings framework, services
DO WORK with 1.2.2 Hotspot, but they don't work with any 1.3 prerelease.
Tue May 09 11:03:21 PDT 2000
bryanvv <mailto:[EMAIL PROTECTED]>
Looks like this is still a problem with the released version
of 1.3 on NT. It causes JRun or JWS (or, presumably, any
Java-based web or application server) to crash on logout,
meaning 1.3 is unuseable on the server for us.
Tue May 09 11:36:21 PDT 2000
mjennings <mailto:[EMAIL PROTECTED]>
The evaluation assumes a separate process is created by
the JVM. This bug occurs when the NT service is a SINGLE
process that uses the JVM.
Something in the hotspot JVM kills the process when the user
logs out. Other services (like MS personal web server) keep
running when user logs out.
Either the process using the JVM crashes, or shuts down
nicely when the user logs off.
Sat May 13 15:30:14 PDT 2000
thobitz <mailto:[EMAIL PROTECTED]>
The reason for this behaviour probably is the setting "Allow Service to
interact with the Desktop". This is
wrong.
A service which has this switch set receives the WM_QUERYENDSESSION on which
each Windows
application is expected to terminate. Furthermore, it can be manipulated by
the user who logged in.
Mon May 15 19:16:27 PDT 2000
SF019JP <mailto:[EMAIL PROTECTED]>
JavaVM stops when works as WindowsNT service at the same time that
a user does log-off. I investigated the cause by referring to SCSL.
JavaVM(JRE1.3) utilizes SetConsoleCtrlHandler() function in Windows
NT and collects some events. When a user does log-off, CTRL_LOGOFF_EVENT
event occurs. As a result JavaVM(JVM.DLL) receives a CTRL_LOGOFF_EVENT
event and has stopped.
I used JNI and evaded this problem by seizing CTRL_LOGOFF_EVENT event
by force. I pray for this problem being solved formally.
Tue May 16 13:31:49 PDT 2000
ken_h_chin <mailto:[EMAIL PROTECTED]>
I'm using JDK 1.3 on Windows NT and have experienced the
same problem. Logging off the user also kills rmiregistry,
which I run as a service using ServiceMaster.
If SUN is serious about supporting server side Java on the
Windows NT platform, this problem has to be fixed. The
performance improvement of 1.3 is great, but we cannot use
it if we can't log off the user without killing our
applications.
We choose Java on Win NT as our development platform
because it allowed us to have the flexibility to choose
more scalable platforms (ie SUN) in the future, while
taking advantage of the lower start up costs of the PC
platform. Making server side Java unusable on Win NT will
make this a less attractive option.
Tue May 16 14:14:02 PDT 2000
Tue May 16 14:20:59 PDT 2000
srinin <mailto:[EMAIL PROTECTED]>
We use ServiceMaster to wrap our Java applications as
services on NT. With JDK1.2.2, the services continued to
work even after the user logged out. In JDK 1.3, the
services stop as soon as the user logs out. This is a huge
problem for us in our production environment, as we want
our server side java applications to restart automatically
after a power failure or reboot.
We can not migrate to JDK 1.3 until this bug is fixed or a
workaround is provided.
Tue May 16 17:14:34 PDT 2000
tsugane
same problem happen with java2-sdk1.3.0 on win2000
and winNT4.0.
application is JRUN2.2.3 and Jakarta-tomcat-NT-service1.1.
Tue May 30 06:56:47 PDT 2000
djcraz_e <mailto:[EMAIL PROTECTED]>
This is a serious bug!!! I cannot advise my company to use the JDK 1.3 if
this kind of know bug is allowed to
remain! It will seriously hamper our web development process to have to code
our services around having a
user logged on at all times!
Tue May 30 06:59:16 PDT 2000
BobW1
This problem needs to be resolved. Our web server was
shutdown about a dozen times (affecting about 8 developers
each time) before we discovered that HotSpot was causing
our web server (IIS) to go down. IIS was going down since
our servlet engine was using 1.3 and was tied into IIS.
We've now gone back to classic JVM 1.2.2 to prevent our web
server from going down.
Fri Jun 02 19:20:49 PDT 2000
briano <mailto:[EMAIL PROTECTED]>
This is not a bug in the VM, but the service wrapper. The service wrapper
that I wrote (specifically for
Java2) doesn't have any problem with JDK1.3 when the user logs out. Even for
JDK1.2 I had to
provide my own handler with SetConsoleCtrlHandler in order to keep the
service running when logging out.
The key difference may be that I also had to call AllocConsole in order for
the handler to get properly
registered.
Wed Jun 07 03:29:40 PDT 2000
huykman <mailto:[EMAIL PROTECTED]>
I would say this is a bug, it doesn't matter in what part
of java it occures. To take java 1.3 seriously on NT, it
should work at least as good as 1.2 versions.
I've tried jdk 1.3 on TomCat 3.1 & Jrun 3.0 and both gave
the same problem.
Mon Jun 12 11:19:32 PDT 2000
briano <mailto:[EMAIL PROTECTED]>
I've been getting a bunch of questions from people regarding my Java service
wrapper. Although I developed
it for my company and it is proprietary, I can still offer pointers. I
developed it last year for JDK1.2, but it
works just fine with JDK1.3 without any modifications. Unlike some other
service wrappers that spawn off
another process, this one creates a JVM in the same process using the
invocation API. I install my console
event handler immediately after I've created the JVM, in order for it to be
called first. Now, I didn't have any
luck at this (under JDK1.2 even) until I added a call to AllocConsole at the
beginning of the service's start
callback. I think this is the magic step in order to make this work
reliably. Calling AllocConsole does not
produce a visible console window unless the service is set to interact with
the desktop. Here's a skeleton
version of my console event handler:
// Console event handler routine.
BOOL handlerRoutine(DWORD dwCtrlType) {
switch (dwCtrlType) {
case CTRL_C_EVENT:
case CTRL_CLOSE_EVENT:
case CTRL_SHUTDOWN_EVENT:
// Call method to stop service
...
return TRUE;
case CTRL_LOGOFF_EVENT:
// Ignore logoff events.
return TRUE;
}
// Let parent handler (the VM) take care of anything else.
return FALSE;
}
Tue Jun 13 07:50:05 PDT 2000
bgiel <mailto:[EMAIL PROTECTED]>
Thanks for posting the above. Unfortunately, the workaround cannot be
implemented with canned wrappers
like SRVANY and others that generically install services including, but not
limited to, Java. The problem
persists when JDK 1.3's java.exe is spawned by the service wrapper (rather
than using JNI invocation.) I
believe this needs to be addressed by JavaSoft so that the JDK 1.3 runtime
responds to a logoff in the same
manner as JDK 1.2.2.
Tue Jun 13 15:30:32 PDT 2000
briano <mailto:[EMAIL PROTECTED]>
JDK1.2.2 didn't actually respond correctly to the logoff event or close
event. Instead of stopping the
process, these would cause a thread dump to be printed to error out just
like with ctrl-break. If JDK1.3
ignored the logoff event completely, then when a user running a client app
logs out from windows, the VM
might not shut down gracefully and the Java exit hooks won't get invoked.
I'm not sure if the VM could tell
whether it was being run as a service or not. If its running as a service,
the logoff event can be ignored,
but it cannot be ignored otherwise.
Wed Jun 14 05:00:23 PDT 2000
pillon <mailto:[EMAIL PROTECTED]>
A solution is to write a genric launcher class in java.
The launcher will just overide 'handlerRoutine' with JNI
and then call your main class with the proper parameters.
To execute 'com.company.server.Main arg1 arg 2' as a sevice
you'll execute 'Launcher com.company.server.Main arg1 arg
2' instead.
This can be used with virtually any service wrapper.
Thu Jun 15 02:17:09 PDT 2000
ArionYu <mailto:[EMAIL PROTECTED]>
I agree that application run by the clients should be stopped after logout,
if not specified purposely (eg
install as service).
If JavaSoft can kindly develop a NT service wrapper for Java application, I
think the problem would be
solved. At least the JavaSoft developers won't need to have JVM support most
(if not all) wrappers.
Thu Jun 15 18:36:20 PDT 2000
gdaswani
Anybody know when this will be fixed?
Fri Jun 16 13:20:13 PDT 2000
nywarrior <mailto:[EMAIL PROTECTED]>
This is a bug!! I had the same problem installing a java
based service with invoker.exe, and had to revert back to
jre1.2.2. This problem seemed to be introduced in jre1.3.
Everything works fine for me using jre1.2.2.
Thu Jun 22 23:57:25 PDT 2000
pgaston
take a look at
http://www.kcmultimedia.com/javaserv/
for working JNI service wrapper
Mon Jun 26 08:50:17 PDT 2000
glabelle <mailto:[EMAIL PROTECTED]>
We picked up an excellent NT Service package at
http://jsrvany.sourceforge.net . It includes C++ source
for the service installer and runtime wrapper, and nice Java classes which
make it easy to implement
handlers for the NT Service events, including "stop"/"pause"/"continue",
which was lacking in most of the
other packages we evaluated.
The jsrvany package doesn't solve the the JDK 1.3 bug, but I think it's an
excellent base on which to
experiment with briano's SetConsoleCtrlHandler() / AllocConsole() solution.
Mon Jun 26 19:04:13 PDT 2000
subc <mailto:[EMAIL PROTECTED]>
It's like "Hotel California"... you can check in BUT can't check out. We
just found
it the hard way... in PRODUCTION... while doing a $3 Billion Dollar Trade in
Java...
thanks to JavaSoft for making me look like a moron in front of my users!!!
Few more bugs like this... the users will force us back to doing Demo
programs in JDK 1.1.0!!!
Not even a patch release!!! I got a better idea... why don't you CLOSE this
bug - like you
do with all other critical ones!!! Mark it un-reproducible with NT Service
Pack 9.8.7.6.5.4.3.2.1.
Wed Jun 28 22:34:44 PDT 2000
develcon <mailto:[EMAIL PROTECTED]>
I know it is humiliating to chase MS with the NT/2k Server "service" mess,
but your customers really need
robust support to provide competitive Java(tm) applications. In my opinion
if you don't support "service's"
then you don't support Windows.
Please deliver a complete solution (included with the JDK), and fix this bug
too.
Fri Jul 07 13:10:20 PDT 2000
adepue <mailto:[EMAIL PROTECTED]>
In case anyone is interested, I have recently posted a free
utility that allows you to run your Java app as an NT
service. It shields the JVM from the NT logoff event (by
running the JVM in the service process and handling the
related events) AND (optionally) allows you to specify a
method in your Java code to perform graceful shutdowns when
the service is stopped. Check out
http://www.eworksmart.com/jnt
Sat Jul 08 10:33:52 PDT 2000
dynaware <mailto:[EMAIL PROTECTED]>
I just patched my Java Service Launcher with the above described
AllocConsole, SetCosnsolCtrlHAndler
approch. It's available at www.roeschter.com.
Moreover I want to point out that there is also a solution for all those
using off the shelf service launchers.
It's feasable to recompile the java.exe from SUN's sources with a small
patch which catches the
LOGOFF event.
This can be achieved by installing the ControlHandler after the JVM has been
initialized but before
the main() method is called.
For details please contact me at [EMAIL PROTECTED]
or look into for the source of my JSL (specifically java.c)
at www.roeschter.com
Sun Jul 09 04:49:33 PDT 2000
macpeep
Ok, this bug has enough votes.. They get the point.. Please
vote for this bug instead: (4314208)
http://developer.java.sun.com/developer/bugParade/bugs/43142
08.html
That bug is a serious screen distortion for several widgets
on Java 1.3 on Win32 on some hardware setups. It makes 1.3
apps with GUI's totally unfeasible since they won't work on
many very common systems.
Wed Jul 19 08:29:09 PDT 2000
k30a2e7 <mailto:[EMAIL PROTECTED]>
Why not just add a "-Xservice" command line option that will make the JVM
not respond to the
CTRL_LOGOFF_EVENT? This should be really easy to implement, and would take
care of this bug for good...
Sat Jul 22 20:22:34 PDT 2000
druble
Fix ASAP please!
Wed Jul 26 14:27:35 PDT 2000
xxh1 <mailto:[EMAIL PROTECTED]>
As of July 25 javaserv doesn't handle this, though it claims to.
I modified javaserv source using jsl source code as a model and
ended up with a working solution. I passed on jsl because it
appeared to rely on the service monitoring a socket. I may
reevaluate my decision. Anyway -- key point is that you'll
just get frustrated if you use javaserv out of the box -- modify
it as per jsl!
Thu Jul 27 14:30:39 PDT 2000
the_hendrys <mailto:[EMAIL PROTECTED]>
This is a Bug!! Our process works fine using 1.2.2, but when using 1.3, a
log-out kills the process.
Fri Jul 28 14:54:39 PDT 2000
b.c
This is indeed a pretty nasty bug.
I hope Sun gets with it and fixes it as there
are a LOT of people who need to be able
to have services running when a user merely logs out.
Fri Jul 28 17:45:39 PDT 2000
westly <mailto:[EMAIL PROTECTED]>
We use ServiceMaster to wrap our Java applications as
services on NT. With JDK1.2.2, the services continued to
work even after the user logged out. In JDK 1.3, the
services stop as soon as the user logs out. This is a huge
problem for us in our production environment, as we want
our server side java applications to restart automatically
after a power failure or reboot.
We can not migrate to JDK 1.3 until this bug is fixed or a
workaround is provided.
Thu Aug 03 05:27:53 PDT 2000
buiret <mailto:[EMAIL PROTECTED]>
I also say that this is a bug: I use RunExecSvce from WinWinsoft and it
works well with JRE 1.2 but not
at all with JRE 1.3.
I took me a long time to identify the problem !
Tue Aug 08 11:41:03 PDT 2000
kenchen <mailto:[EMAIL PROTECTED]>
This is a HotSpot bug! It happens when you use JDK with
HotSpot. JDK 1.3 comes with HotSpot by default. I tried
different combinations with JDK 1.2.2, 1.3 with/without
HotSpot on ServletExec 3.0 and the only combination work is
JDK 1.2.2 Classic. Others kill IIS when a user logs out.
Tue Aug 08 16:53:45 PDT 2000
kurt <mailto:[EMAIL PROTECTED]>
This problem also manifests itself when the JVM is started
by the JNI Invokation API (JNI_CreateJavaVM()) instead of
the service doing CreateProcess on java.exe. This is with
JDK 1.3 on Windows 2000.
In this case, a thread is creating the JVM and calling into
a static Java method that is designed to not return. When
the user logs out, that thread is destroyed without
returning from the static Java method.
Tue Aug 29 05:58:09 PDT 2000
Anja.Niebler <mailto:[EMAIL PROTECTED]>
Here is the complete c code of a NT-Service starter, that
stays, if it got an LOGOFF-Event.
And additionaly a excample of a java class.
The most important part is to LEAVE the main method of the
java-class, so that a CtrlHandler can be installed after
calling the main method of the java-class.
///////////////////////////////////////////////////////////
// Program, that starts the java virtual machine and
handles console events by itself
// This program can be used for starting an NTService with
JDK 1.3.0
// includes
#include <jni.h>
#include <windows.h>
#include <string.h>
// typedefs
typedef jint (*P_JNI_GetDefaultJavaVMInitArgs)(void *args);
typedef jint (*P_JNI_CreateJavaVM)(JavaVM **pvm, JNIEnv **
penv, void *args);
/***********************************************************
*****************
Usage of the program.
************************************************************
****************/
void printInfo()
{
printf("no parameter found.\n");
printf("Usage: \n");
printf("Parameters are.\n");
printf("arg[1] : jvm library e.g.
c:\\jdk\\jre\\bin\\classic\\jvm.dll \n");
printf("arg[2] : classpath
e.g. c:\\myclasses\\myproject.jar \n");
printf("arg[3] : lib-path
e.g c:\\mylibs \n");
printf("arg[4] : java-class-file e.g. MyMain
\n");
printf("arg[5]ff: additional parameters for main-
method in MyMain.class\n");
}
/***********************************************************
*****************
static globals.
************************************************************
****************/
static HMODULE hLib
= NULL;
static JavaVM *jvm
= NULL;
static JNIEnv *env
= NULL;
static JavaVMInitArgs vm_args;
static jclass clsMain
= NULL;
static jclass clsString
= NULL;
static jmethodID midMain
= 0;
static JavaVMOption options[20];
/***********************************************************
*****************
Invoke JVM and call of the static main method of the
given javaclass
************************************************************
****************/
int __cdecl invokeJVM(int argc, char* argv[])
{
P_JNI_GetDefaultJavaVMInitArgs
pfnGetDefaultJavaVMInitArgs = NULL;
P_JNI_CreateJavaVM
pfnCreateJavaVM =
NULL;
jint
res
= -1;
jstring
jsTemp;
jarray
stringArray;
char
clsOptions[255];
char
libOptions[255];
char
jvmLibrary[255];
char
czTemp[100];
int
i;
// Load JVM library (jvm.dll)
strcpy (jvmLibrary, argv[1]);
hLib = LoadLibrary(jvmLibrary);
if(hLib == NULL)
{
printf ("Cannot load library %s",
jvmLibrary);
return 0;
}
// ClassPath
strcpy (clsOptions, "-Djava.class.path=");
strcat (clsOptions, argv[2]);
// LibPath
strcpy (libOptions, "-Djava.library.path=");
strcat (libOptions, argv[3]);
// JDK 1.3.0 Options
options[0].optionString = clsOptions;
options[1].optionString = libOptions;
vm_args.version = JNI_VERSION_1_2;
vm_args.options = options;
vm_args.nOptions = 2;
vm_args.ignoreUnrecognized = TRUE;
// Create JavaVM
pfnCreateJavaVM = (P_JNI_CreateJavaVM)
GetProcAddress(hLib, "JNI_CreateJavaVM");
if(pfnCreateJavaVM != NULL)
{
res = (*pfnCreateJavaVM)
(&jvm,&env,&vm_args);
if (res < 0)
{
printf("Error! Cannot create Java
VM");
return 0;
}
}
else
{
printf("Error! Cannot create Java VM,
function pointer = null");
return 0;
}
// FindClass argv[4]
clsMain = (*env)->FindClass(env, argv[4]);
if (clsMain == 0)
{
printf("Cannot find Class %s", argv[4]);
return 0;
}
// FindClass String
clsString = (*env)->FindClass
(env, "java/lang/String");
if (clsString == 0)
{
printf("Cannot find Class String");
return 0;
}
// get methodId of Main.main
midMain = (*env)->GetStaticMethodID(env,
clsMain, "main", "([Ljava/lang/String;)V");
if (midMain == 0)
{
printf("Cannot find Method %s.main", argv
[4]);
return 0;
}
// prepare the StringArray for the main-method of
the java class
strcpy (czTemp, argv[0]);
jsTemp = (*env)->NewStringUTF (env, czTemp);
if (argc>5)
stringArray = (*env)->NewObjectArray(env,
argc-5, clsString, jsTemp);
else
stringArray = (*env)->NewObjectArray(env,
0, clsString, jsTemp);
if (stringArray == 0)
{
printf("Cannot create String Array");
return 0;
}
for (i=5; i<argc; i++)
{
strcpy (czTemp, argv[i]);
jsTemp = (*env)->NewStringUTF (env, czTemp);
(*env)->SetObjectArrayElement(env,
stringArray, i-5, jsTemp);
}
// call Main.main
// remark: Ensure, that the main method of the java-
class returns.
// If the java-class is a server application, the
application should start
// as an own thread.
(*env)->CallStaticVoidMethod(env, clsMain, midMain,
stringArray);
return 1;
}
// Console event handler routine.
// returns true, if the event will be handled by this
routine
// returns false, if the parent handler is responsible for
the event
BOOL WINAPI CtrlHandler(DWORD fdwCtrlType)
{
switch (fdwCtrlType)
{
case CTRL_C_EVENT:
{
// for future releases...
// call here a exit methode
of the Java-class
printf("got Ctrl C\n");
return FALSE;
break;
};
case CTRL_CLOSE_EVENT:
{
printf("got CloseEvent\n");
return TRUE;
break;
};
case CTRL_SHUTDOWN_EVENT:
{
printf("got
ShutdownEvent\n");
return TRUE;
break;
};
// react on this event to install a service
on WinNT-Server with JDK 1.3.0
case CTRL_LOGOFF_EVENT:
{
printf("got
ShutdownEvent\n");
return TRUE;
break;
};
}
return FALSE;
}
int __cdecl main(int argc, char* argv[])
{
int res=0;
BOOL fSuccess;
HANDLE hServerStopEvent = NULL;
if (argc<5)
{
printInfo();
return 0;
}
// Create a Stop Event
hServerStopEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
// start java virtual machine
printf("Starting VM...");
res = invokeJVM(argc, argv);
if (res!=0)
{
printf("VM started...");
}
else
{
printf("cannot start VM !");
return 0;
}
// install the CtrlHandler
fSuccess = SetConsoleCtrlHandler((PHANDLER_ROUTINE)
CtrlHandler, TRUE); // add to
list
if (! fSuccess)
{
printf("Could not set control handler");
return 0;
}
else
{
printf("set control handler");
}
//wait
WaitForSingleObject(hServerStopEvent,INFINITE);
return 0;
}
/**
* Class T, excample for starting an NT Service
*/
class T
{
public static void main( String[] args )
{
// Most important: start an own thread
Thread t= new Thread()
{
public void run()
{
while (true)
{
System.out.print("in Thread...\n");
try
{
sleep(1000);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
};
t.start();
System.out.print(args[0]);
// then exit the main method
};
};
Thu Sep 14 13:49:53 PDT 2000
ebony_prince2 <mailto:[EMAIL PROTECTED]>
How do I get back my virtual machine?
Mon Sep 18 06:43:30 PDT 2000
javafarabi <mailto:[EMAIL PROTECTED]>
Problem browsing applet in environment Mac Netscape, you
have have reponse. plis sending your message======>
Message error
8/25/2000 @ 15:54:53
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/11/2000 @ 13:27:23
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/11/2000 @ 13:28:18
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/12/2000 @ 11:30:45
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
[EMAIL PROTECTED]
Mon Sep 18 06:46:45 PDT 2000
javafarabi <mailto:[EMAIL PROTECTED]>
Problem browsing applet in environment Mac Netscape, you
have have reponse. plis sending your message======>
Message error
9/16/2000 @ 15:54:53
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/11/2000 @ 13:27:23
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/11/2000 @ 13:28:18
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/12/2000 @ 11:30:45
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
at
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
[EMAIL PROTECTED]
<http://developer.java.sun.com/servlet/PrintPageServlet> Print Button
[ This page was updated: 21-Sep-2000 ]
By Alê!
printbutton.gif
------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------
printbutton.gif