|
From: Paul C. <cas...@au...> - 2004-06-11 03:51:46
|
Hi again. I'm now able to replicate this JVM exit consistently, so I turned on debug. However, I only got 1 more line of logging: DEBUG | wrapper | 2004/06/11 08:46:07 | Got ping response from JVM INFO | jvm 1 | 2004/06/11 08:46:09 | DEBUG | wrapper | 2004/06/11 08:46:09 | JVM process exited with a code of 128, setting the wrapper exit code to 128. ERROR | wrapper | 2004/06/11 08:46:09 | JVM exited unexpectedly. DEBUG | wrapper | 2004/06/11 08:46:09 | Waiting 5 seconds before launching another JVM. STATUS | wrapper | 2004/06/11 08:46:13 | Launching a JVM... I've done a search in the Java forums and on the web, but can't find any info on the exit code 128 for the JVM. Has anyone seen something like this before, or does any have any other ideas / suggestions? Regards, Paul Casanova Hi all, Our application crashed this morning after a user attempted a print using a Lexmark Optra Color 45 driver. We haven't had an issue with this driver before, so it has me baffled. Here's a timeline of the facts that I can gather: 9:38:05 A blank line was logged by the Java Service Wrapper. This suggests that an error was thrown by the JVM, but it didn't get to log it because: 9:38:06 The JVM exited without any error information. 9:38:06 The Windows Event Log shows the Lexmark Optra Color 45 completing a print process (ie generating a plot file) - although the resultant file was 0 bytes in length. A PrinterException should have been thrown by the printing process, but it shouldn't have made the JVM crash. We're using 1.3.1_11. Here's the output of the JSW log file at that time: INFO | jvm 1 | 2004/06/09 09:38:05 | ERROR | wrapper | 2004/06/09 09:38:06 | JVM exited unexpectedly. STATUS | wrapper | 2004/06/09 09:38:10 | Launching a JVM... INFO | jvm 2 | 2004/06/09 09:38:10 | Wrapper (Version 3.1.0) http://wrapper.tanukisoftware.org INFO | jvm 2 | 2004/06/09 09:38:10 | Why the blank lines? There had been no activity between 9.34 and 9.38am, so the info above this in the log file is not relevant. I thought I had the JSW configured to dump out thread stuff on exit. Here's my conf details: # Request a thread dump on JVM exit wrapper.request_thread_dump_on_failed_jvm_exit=true #******************************************************************** # Wrapper Logging Properties #******************************************************************** wrapper.console.format=LPTM wrapper.console.loglevel=INFO wrapper.logfile=%RCIS_HOME%\Service\logs\RCISMainServer.log wrapper.logfile.format=LPTM wrapper.logfile.loglevel=INFO wrapper.logfile.maxsize=1m wrapper.logfile.maxfiles=100 wrapper.syslog.loglevel=ERROR # Allow the service to interact with the desktop. wrapper.ntservice.interactive=false # Disable the wrapper startup timeout facility wrapper.startup.timeout=0 # Enable the wrapper exit timeout facility so that the JVM will be terminated if shutdown fails wrapper.jvm_exit.timeout=120 # Enable the wrapper shutdown timeout facility so that the JVM will be terminated if shutdown fails wrapper.shutdown.timeout=120 # Extend the wrapper ping timeout facility to prevent restarting under normal operation (10 minutes) wrapper.ping.timeout=300 Does this all look reasonable? I'd rather not have debug on all the time if we can get away with it - a problem like this might not occur for another few months, but I'd like to be able to explain it to the client when and if it does. Any ideas would be greatly appreciated. Regards, Paul Casanova |