Java wrapper error

My Program is not running as fast as I expect.

My Program is not running as fast as I expect.

In general, an application should run as fast under the Wrapper as it does when running standalone.
Here are a few places to start looking.

Console Output

On some platforms, including Windows, sending large quantities of text to
System.out or System.err
will cause the program to slow down.
This is because all of that output is being rendered to the screen in a GUI environment.
This is actually the OS eating the CPU rather than the Wrapper or your application,
but the end result is the same.

To significantly reduce this effect, use a logging tool that will output to a file rather than to stdout.
By doing so, the output is never sent to the Wrapper or the user console and it results in reducing the burden.

Another option, which is almost as good, is to configure the Wrapper’s console log level,
using the wrapper.console.loglevel property,
so that the output is only sent to the Wrapper’s log file.
Console output is disabled by default when running as a Windows Service
and the console has not been enabled.

Memory

Make sure that your system has plenty of physical memory for the JVM to run
without doing any disk swapping (virtual memory on hard disk).
Because of the way Java manages memory, a very significant speed hit is common simply
because Java is forced to do paging of large amounts of its memory
as it attempted to perform «garbage collection».

I am getting an error that the Wrapper cannot load its native library.

A few users have asked about the following message showing up
in their wrapper.log file:

WrapperManager: ERROR - Unable to load the Wrapper's native library because none of the
WrapperManager:         following files:
WrapperManager:           wrapper-windows-x86-64.dll
WrapperManager:           wrapper.dll
WrapperManager:         could be located on the following java.library.path:
WrapperManager:           E:myworkspacetortoisewrapperwrapper_3.5.xprofessionalbin..lib
WrapperManager:         Please see the documentation for the wrapper.java.library.path
WrapperManager:         configuration property.

This message is being shown because the Java component of the Wrapper was unable to load its
native libraries during initialization.
If you look in your wrapper.conf file,
you will see a property, wrapper.java.library.path.
This property is used to specify the directory that the Wrapper will look in to find its native library
(Windows: wrapper.dll, Linux/UNIX: libwrapper.so).
You should place the library file in the specified directory
or change the property to point to the directory where the library is located.

If you are using the Delta Pack, make sure that the library corresponding to your platform is located in the specified directory.

My application does not start. What can I do to narrow down the problem?

Output describing the problem should be displayed in the console,
as well as the configured log file.
To get more detailed output,
edit your wrapper.conf file and
enable debugging by uncommenting the wrapper.debug property.
This will display very detailed output at every step in the process of launching and monitoring your application.

If your application works when not using the Wrapper, but fails with the Wrapper,
then it is very likely that there is a problem in the way you set up your wrapper.conf file.
Please look closely at the command used to launch Java in the debug output.
It is possible that there is a mistake in the classpath or something.

I am not getting any output in my configured log file.

It is possible that the Wrapper is not able to locate the specified Wrapper configuration file,
or it is not able to open the configured log file for some reason.
In either case, the Wrapper will log output to
a file called wrapper.log
in the current working directory.
The current working directory will most likely be the directory containing the binary.
However, in some cases, when running as a Windows Service, the
wrapper.log file
may be placed in your system directory (WinNTSystem32).

My application is hanging while it is shutting down.

If you call System.exit() in your application,
then the Wrapper will catch this and attempt to shutdown the application cleanly.
If during the shutdown process your application once again calls System.exit(),
then the call will block indefinitely, causing your application to hang.
There are also problems with calling the destroy() method
on an AWT frame or window from within a Shutdown Hook thread.
Please take a look at the
wrapper.disable_shutdown_hook property
in the Configuration Overview for details on how to avoid this problem.

My JVM hangs when shutting down after doing a thread dump.

The problem is that you might set the
wrapper.java.command
property to a batch file rather than directly to java.exe.
When requesting a thread dump, the «BREAK» signal is being sent to
the process command.exe/shell rather than the Java process.
It then forwards the signal on to the JVM, but also sets an internal flag that CTRL-C has been pressed.
Before the Java process exits, it asks the user if they wish to stop or continue the batch script.

INFO   | jvm 1    | 2009/10/23 14:30:35 | WrapperManager Debug: Sent a packet STOPPED : 0
INFO   | jvm 1    | 2009/10/23 14:30:36 | Terminate batch job (Y/N)?
ERROR  | Wrapper  | 2009/10/23 14:30:56 | Shutdown failed: Timed out waiting for the JVM to terminate.
ERROR  | Wrapper  | 2009/10/23 14:30:56 | JVM did not exit on request, terminated
STATUS | Wrapper  | 2009/10/23 14:30:57 | <-- Wrapper Stopped

If you are needing to do some additional processing before or after
the JVM is launched, the Java Service Wrapper Professional edition has the ability to do
exactly that: Wrapper Event Configuration.

I can’t use the API call WrapperManager.requestThreadDump (Error 0x57)

This problem is similar and caused by the same reason as the previous mention above.

INFO   | jvm 1    | 2009/10/23 14:35:48 |  WrapperJNI Error: Unable to send BREAK event to JVM process: The parameter is incorrect. (0x57)

If you are needing to do some additional processing before or after
the JVM is launched, the Java Service Wrapper Professional edition has the ability to do
exactly that: Wrapper Event Configuration

JBoss 6.* is outputting lots of «ERROR: Error installing to…» Errors at start-up when running with the Wrapper

INFO   | jvm 1    | 2011/01/06 17:23:05 | ERROR: Error installing to Configured: name=ServiceBindingManager state=Configured
INFO   | jvm 1    | 2011/01/06 17:23:05 | java.lang.Exception: Error calling callback JMXRegistrationAdvice for target context ServiceBindingManager
...

JBoss with version 6 is utilizing internally a MBeanServer Factory based on
org.jboss.system.server.jmx.MBeanServerBuilderImpl,
however, this one is incompatible to the default
JVM MBeanServerBuilder (javax.management.MBeanServerBuilder).

There are 2 options available to resolve this.
First option is to disable the Wrapper’s MBeans from getting registered.
For this option, please take a look at Integration Method 1.
The second option is to tell the JVM to use the MBeanServer Factory that JBoss is using.
More information about this can be found on the JMX Page.

The Wrapper is reporting an error/warning about its signature when starting.

wrapper  | A signature was found in "C:wrapper-windows-x86-32-3.5.7-probinwra
pper.exe", but checksum failed: (Errorcode: 0x800b010a) 
A certificate chain could not be built to a trusted root authority. (0x800b010a)
wrapper  |   Signer Certificate:
wrapper  |     Serial Number: 
wrapper  |       00 97 06 fe b5 6e 56 cc cb 66 3a bb 55 a7 a0 e4 76 
wrapper  |     Issuer Name: UTN-USERFirst-Object
wrapper  |     Subject Name: Tanuki Software Ltd.
wrapper  |   TimeStamp Certificate:
wrapper  |     Serial Number: 
wrapper  |       47 8a 8e fb 59 e1 d8 3f 0c e1 42 d2 a2 87 07 be 
wrapper  |     Issuer Name: UTN-USERFirst-Object
wrapper  |     Subject Name: COMODO Time Stamping Signer
wrapper  |     Date of TimeStamp : 2010/12/19 22:32
wrapper  | The Wrapper will shutdown!

Starting with Wrapper version 3.5.7, the Windows binaries (i.e.
wrapper.exe, wrapperW.exe and wrapper.dll)
of all Wrapper Editions (Community, Standard, Professional) are using codesigning to verify the origin of the file
from being from Tanuki Software. If any problem was detected, the Wrapper will shutdown.

Starting with Wrapper version 3.5.28, the Wrapper is signed with a SHA-2 certificate that provides stronger security than the previously used SHA-1 algorithm. The decision to change the certificate was made in compliance with Microsoft’s SHA-1 deprecation plan, which states that Windows 7 and higher will no longer support SHA-1 after January 1st, 2016.

The above error occurs when the certificates provided by our counter-signer ‘Comodo’ are not correctly installed.

The certificates should be installed in a store that is accessible from the account on which the Wrapper is running. When the Wrapper is running as a console application, this may be the current user. When running as a service, it should be accessible from the service account that it uses. An alternative to this is to install the certificate to the local machine so that it is accessible in both modes.

The installed certificates can be investigated from the Windows Certificate Manager certmgr.msc (for the current user) or mmc (for any user).

To manage the certificates of a specific account, launch ‘mmc’ from the Windows Run search box. On the File menu, click ‘Add/Remove Snap-in’ and double click on ‘Certificates’. You can then choose to either manage certificates of the current user, of a service account or of the computer account. In the case of the service account, a list will appear with all services installed on the computer. You should select the name used when installing the Wrapper as a service.

Two certificate installations are possible. You will find below the link to download the certificates from the Comodo website:

  • Cross-signed certificates issued by AddTrust External CA Root (addtrustexternalcaroot.crt, comodorsaaddtrustca.crt and comodorsacodesigningca.crt) are suitable for all versions of the Wrapper, and more compatible with legacy devices using old versions of the Windows:

    https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/985/108/code-signing-sha-2

    Using ‘mmc’ or ‘certmgr.msc’, you can confirm the following installation:

    • «AddTrust External CA Root» should be installed under «Trusted Root Certificate AuthoritiesCertificates».

    • «COMODO RSA Certification Authority» and «COMODO RSA Code Signing» should be installed under «Intermediate Certification AuthoritiesCertificates».
      Make sure that their signature hash algorithms match the version of the Wrapper you are using (sh384 or sha-2 for Wrapper 3.5.28 and above, and sha-1 for earlier versions). This can be checked by double clicking on the certificate and opening the ‘Details’ tab. You may also check that these certificates are enabled in the properties window accessible from the context menu.

    • «UTN-USERFirst-Object» should be installed under «Third Parties Root Certification AuthoritiesCertificates».

  • The Comodo RSA Certification authority Root (comodorsacertificationauthority.crt) is a single certificate that only works with SHA-2 signed binaries (Wrapper 3.5.28 and above):

    https://support.comodo.com/index.php?/Knowledgebase/Article/View/969/108/root-comodo-rsa-certification-authority-sha-2

    Using ‘mmc’ or ‘certmgr.msc’, you can comfirm the following installation:

    • «COMODO RSA Certification Authority» issued by «COMODO RSA Certification Authority» should be installed under «Third Parties Root Certification AuthoritiesCertificates».

To install the certificates for the current user or the local computer, you may simply execute the .crt file and follow the installation steps.
To import them to a service user, use ‘mmc’, add the snap-In as described above, select any store (marked with a folder icon) under this snap-In on the left panel, and from the menu click on ‘Action > All tasks > Import’ (Choose the option to «Automatically select the certificate store based on the type of certificate»).

If the error is still showing, this might mean that the Local Security Policy of the server is too strict to allow the certificates to be verified. This settings can be found in the Local Security Policy of the server.
Launch ‘secpol.msc’ from the Windows Run search box, click on «Public Key Policies», then «Certificate Path Validation Settings». Under the ‘Stores’ tab, make sure that «Third-Party Root CAs and Enterprise Root CAs» is checked if policy settings are defined.
If this doesn’t/can’t be set to active, another option would be to move the «UTN-USERFirst-Object Certificate»
from the «Third Party Root CA» folder to the «Trusted Root Certificate Authorities» folder.

In Wrapper version 3.5.8, the Wrapper will only shut down if the reason why
the signature wasn’t verified was caused directly by the Wrapper, and not due to the counter-signer.

In Wrapper version 3.5.7, there was a bug potentially causing an access violation,
when the Signature verification failed and the Wrapper was trying to report the error.

Since Wrapper version 3.5.34, the Wrapper binaries are dual signed
with SHA-1 and SHA-2 hash algorithms to allow stronger verification at the OS level.
To verify algorithms and timestamps, right click on the binaries and open the «Properties» window from the
contextual menu, then select the «Digital Signatures» tab:

Note that the SHA-256 hash algorithm will not appear on old versions of Windows where this algorithm is not supported.
Microsoft published an update
for Windows 7 and Windows Server 2008 R2 to add support for SHA-2.
If this update is present, you will be able to verify the SHA-2 hash, else you will only be able to verify the SHA-1 hash.
More recent versions of Windows don’t require this update, as they already support SHA-256,
while older versions (Windows XP, Vista, Windows Server 2008) can only verify SHA-1 hashes.

You can confirm that a digital signature is valid by clicking on it in the signature list:

Finally, it should be noted that Windows XP SP2 and lower, as well as Windows Server 2003, don’t support SHA-2 and the new certificate will not apply on these platforms. The binaries provided for Windows Itanium will also no longer be signed.

Why is the Wrapper trying to access an external Comodo server?

The Wrapper itself does not actually try to access the Comodo or other servers, but starting with Wrapper version 3.5.7,
the binaries are now signed with a Comodo certificate.
This is important to help the OS verify that the Wrapper binaries are actually from Tanuki Software.

When Windows tries to launch a signed binary, it will first check the binary to make sure that it matches the signature to ensure that the binary has not been tampered with.
Normally the Comodo certificate needed to verify the binary will exist on a Windows machine, but in some cases the OS will need to go out to the Internet and download it from a known location.
The connection will happen as the Wrapper is being launched, but before it is actually started.
It can appear, however, as if the Wrapper is what is making the connection.
We have had reports of the following servers being accessed in this way: ocsp.comodoca.com, a125-56.204-123.deploy.akamaitechnologies.com (The IP portion of the akamai servers vary by the request).

If this causes any concern with customers, then one option on the Standard and Professional editions is to Customize your Wrapper binary, as this process removes the signature.
Doing so will, of course, remove the OS’s ability to verify the authenticity of the binary, however.

I can only run -N- services on Windows.

The Wrapper itself does not place any restrictions on the number of Wrapper instances
that can be run on Windows at the same time, but both the Wrapper and especially Java
consume various resources, which can place limits on how many instances can be run on
a given system. The most common resource that causes problems is the Desktop Heap.
Please see the Solving Desktop Heap Problems
page for more information.

How can I specify new Java 9 options that require arguments (such as those used to specify modules)?

Java 9 introduces several options (such as —module-path or —add-modules) that require to be specified with an argument.
Usually the argument is separated from the option name by a space, but any space inside values of the wrapper.java.additional.<n>
properties is interpreted as part of the argument value and not as delimiter.
A solution is to separate the option name and the argument by an equal sign (=) instead of a space.

wrapper.java.additional.1=--add-modules=MODULE1,MODULE2

Note that this will only work with long options (those starting with ‘—‘) and not with their short aliases.
For example, ‘-p=<PATH>’ is not allowed (‘-p’ being an alias of ‘—module-path’).

Another solution that allows you to use both spaces and short aliases, is to use the JDK_JAVA_OPTIONS environment variable.
The content of this variable will be added to the options of the command line by the JVM.
You can set it from the Wrapper configuration file by using the following syntax:

set.JDK_JAVA_OPTIONS=--add-modules MODULE1,MODULE2

Note, however, that you will not be able to visualize the content of JDK_JAVA_OPTIONS when printing the Java command line (using the
wrapper.java.command.loglevel property) as it is only parsed by the JVM when it is launched.

You can read more information about the long options and the JDK_JAVA_OPTIONS variable on Oracle’s website.

How can I solve slow startup times on Linux due to random seed generator?

Java applications that make calls to java.util.Random.nextLong() or other random methods can be very, very slow the first time they are called.
This is caused by a lack of entropy on the system. The call will block until such entropy has build up enough to return a good number.
Unfortunately, on startup when nothing else is happening, this can take a very long time, during which your application will appear to be frozen.

About the only way to detect whether or not this is happening is to issue a thread dump request while it is waiting.
If this is the cause, you should be able to see it easily.

Once this has been identified as the problem, a solution that we have found is to add the following property to your configuration.
This changes the way Java generates random data to a method that is always fast.
We make no claims on how this affects security, so please investigate this and let us know if you have a better solution.
Be sure to use a number which does not overlap with your existing configuration:

# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom

This is a platform-specific solution.
If you need to have a platform-independent configuration, then please create a second wrapper-linux.conf configuration file:

#encoding=UTF-8
# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom

Then, include that based on platform from your main configuration file.
In such cases, we suggest adding a comment in the main configuration to make sure the numbered property is not reused by mistake.

#encoding=UTF-8
#include ../conf/wrapper-%WRAPPER_OS%.conf
...
# Solve slow random initialization on Linux
#wrapper.java.additional.20= # Reserved for use in wrapper-linux.conf

Old issues

I get an error about not being able to write a pid file when starting the Wrapper.

Starting with Wrapper version 3.0.5,
the wrapper.pidfile property
was implemented on the Windows platform.
Previous versions of the Wrapper ignored this property when running under Windows.
However, if the wrapper.conf file
that you are using was created using a version of the Wrapper versions prior to 3.0.0,
then you may have this property defined as a holdout from
when you copied the file from the example wrapper.conf.
This will lead to an error like the following:

ERROR: Could not write pid file /var/run/testwrapper.pid: The
system cannot find the path specified. (0x3)

To resolve this simply edit your wrapper.conf file
and remove the wrapper.pidfile property.

My JVM version 1.2.x crashes when I run my application with the Wrapper.

Please see the list of supported JVMs (Java Virtual Machines).
Java Service Wrapper version 3.4.x or later doesn’t support JVM version 1.2.x any longer.

Most of the features of the Wrapper prior to version 3.4.x will work with version 1.2.x of JVMs.
However, the released version of the Wrapper is built using a 1.4.x version of Java.
1.2.x versions of the JVM have problems with the generated jar and will crash with very low level JNI errors.
This appears to be a bug in the JVM 1.4.x versions of the compiler,
as it happens even if the JVM version 1.1 target is specified when compiling the classes.

Here is an example of the errors that I have seen:

A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in:
  'org/tanukisoftware/wrapper/WrapperManager.stopCommon (II)V': Interpreting method.
  Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi

We get help from several people to be able to produce the releases for all of the various supported platforms
and it is not really possible to force everyone to use old JDKs to build the Wrapper distributions.

If you are experiencing crash problems with JVMs 1.2.x versions and the Wrapper,
please try downloading a source distribution
and building the wrapper.jar file using your JDK 1.2.x version.
This will fix the problem.

If you are running into this, please post a note to the
Wrapper-User Mailing List.
We are not sure how many people are still using 1.2.x JVMs,
but if it is still fairly common, we may reconsider the above policy
and look into what it will take to get the releases built using an older JVM.

My JVM is sometimes restarted when the system is heavily loaded.

As of Wrapper version 3.1.0, a new timer mechanism was added, which allows
the Wrapper to handle cases where it is running in a CPU-starved state reliably because the tick count is incremented at
a rate that reflects the amount of CPU being received, rather than being absolute. This means that timeouts due to high
loads are very unlikely. Just make sure that the wrapper.use_system_time
property is set to FALSE for the timer mechanism to be enabled.

Because the Java Service Wrapper is using a pinging mechanism to check on the health of the JVM,
it is possible that the Wrapper will think that the JVM is hung
when it isn’t if another process is taking 100% of the CPU for longer than 30 seconds.
This will result in an entry similar to the following in your log file, and the JVM being restarted:

jvm 1    | 2001/12/01 12:23:23 | start()
wrapper  | 2001/12/01 12:23:44 | Startup failed: Timed out waiting for signal from JVM.
wrapper  | 2001/12/01 12:23:44 | JVM did not exit on request, terminated
wrapper  | 2001/12/01 12:23:49 | Launching a JVM...
jvm 2    | 2001/12/01 12:23:50 | Initializing...

The property wrapper.ping.timeout=30
in conf/wrapper.conf can be used to extend this timeout.
But be aware that this will also lengthen the amount of time
that your application will remain hung in the event of a real problem.

I can’t start the Wrapper on MacOS Mavericks.

Up until Wrapper version 3.5.22, if you start the Wrapper on MacOS Mavericks, you will see an error.
This is because the script fails to use the 64-bit version of the binaries.

The solution to this issue is to locate, open and edit the following script file src/bin/App.sh.in (on older Wrapper versions, this file was named ‘sh.script.in’).

Open the file (src/bin/App.sh.in):
OS_VER=`sw_vers | grep 'ProductVersion:' | grep -o '[0-9]*.[0-9]*.[0-9]*'`
Please edit the line as follows:
OS_VER=`sw_vers | grep 'ProductVersion:' | grep -o '[0-9]*.[0-9]*.[0-9]*|[0-9]*.[0-9]*'`

Здравствуйте.

Пытаюсь в windows запустить jar как службу.
Для этих целей решил воспользоваться функционалом java wrapper community edition 3.5.29
При старте службы возникает ошибка wrapper при том, что необходимый jar стартует нормально.

#encoding=UTF-8
# Configuration files must begin with a line specifying the encoding
# of the the file.

….
#********************************************************************
# Wrapper Localization
#********************************************************************
# Specify the locale which the Wrapper should use. By default the system
# locale is used.
#wrapper.lang=en_US # en_US or ja_JP

# Specify the location of the Wrapper’s language resources. If these are
# missing, the Wrapper will default to the en_US locale.
wrapper.lang.folder=../lang

#********************************************************************
# Wrapper Java Properties
#********************************************************************
# Java Application
# Locate the java binary on the system PATH:
wrapper.java.command=java
# Specify a specific java binary:
#set.JAVA_HOME=/java/path
#wrapper.java.command=%JAVA_HOME%/bin/java

# Tell the Wrapper to log the full generated Java command line.
#wrapper.java.command.loglevel=INFO

# Java Main class. This class must implement the WrapperListener interface
# or guarantee that the WrapperManager class is initialized. Helper
# classes are provided to do this for you. See the Integration section
# of the documentation for details.
#wrapper.java.mainclass=org.tanukisoftware.wrapper.demo.DemoApp
wrapper.java.mainclass=COM.MainRunner

# Java Classpath (include wrapper.jar) Add class path elements as
# needed starting from 1
#wrapper.java.classpath.1=../lib/wrapperdemo.jar
wrapper.java.classpath.1=../lib/main.jar
#wrapper.java.classpath.2=../lib/wrapper.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib

# Java Bits. On applicable platforms, tells the JVM to run in 32 or 64-bit mode.
wrapper.java.additional.auto_bits=TRUE

# Java Additional Parameters
wrapper.java.additional.1=

# Initial Java Heap Size (in MB)
#wrapper.java.initmemory=3

# Maximum Java Heap Size (in MB)
#wrapper.java.maxmemory=64

# Application parameters. Add parameters as needed starting from 1
wrapper.app.parameter.1=»Oracle»

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Enables Debug output from the Wrapper.
# wrapper.debug=TRUE

# Format of output for the console. (See docs for formats)
wrapper.console.format=PM

# Log Level for console output. (See docs for log levels)
wrapper.console.loglevel=INFO

# Log file to use for wrapper output logging.
wrapper.logfile=../logs/main.log

# Format of output for the log file. (See docs for formats)
wrapper.logfile.format=LPTM

# Log Level for log file output. (See docs for log levels)
wrapper.logfile.loglevel=INFO

# Maximum size that the log file will be allowed to grow to before
# the log is rolled. Size is specified in bytes. The default value
# of 0, disables log rolling. May abbreviate with the ‘k’ (kb) or
# ‘m’ (mb) suffix. For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=0

# Maximum number of rolled log files which will be allowed before old
# files are deleted. The default value of 0 implies no limit.
wrapper.logfile.maxfiles=0

# Log Level for sys/event log output. (See docs for log levels)
wrapper.syslog.loglevel=NONE

#********************************************************************
# Wrapper General Properties
#********************************************************************
# Allow for the use of non-contiguous numbered properties
wrapper.ignore_sequence_gaps=TRUE

# Do not start if the pid file already exists.
wrapper.pidfile.strict=TRUE

# Title to use when running as a console
wrapper.console.title=Test Wrapper Sample Application

#********************************************************************
# Wrapper JVM Checks
#********************************************************************
# Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
wrapper.check.deadlock=TRUE
wrapper.check.deadlock.interval=10
wrapper.max_failed_invocations=99
wrapper.console.fatal_to_stderr=FALSE
wrapper.console.error_to_stderr=FALSE
wrapper.check.deadlock.action=RESTART
wrapper.check.deadlock.output=FULL

# Out Of Memory detection.
# Ignore -verbose:class output to avoid false positives.
wrapper.filter.trigger.1000=[Loaded java.lang.OutOfMemoryError
wrapper.filter.action.1000=NONE
# (Simple match)
wrapper.filter.trigger.1001=java.lang.OutOfMemoryError
# (Only match text in stack traces if -XX:+PrintClassHistogram is being used.)
#wrapper.filter.trigger.1001=Exception in thread «*» java.lang.OutOfMemoryError
#wrapper.filter.allow_wildcards.1001=TRUE
wrapper.filter.action.1001=RESTART
wrapper.filter.message.1001=The JVM has run out of memory.

….
# Specify custom mail content
wrapper.event.jvm_restart.email.body=The JVM was restarted.nnPlease check on its status.n
….

Прошу помочь разобраться в чем проблема.

Debugging Java Wrapper Objects

When running an application that relies on a Java wrapper object, it is often difficult to determine when errors occur in the associated IDL object. Since the instance of the wrapper object is invoked outside of IDL, the normal debugging capabilities of the IDL Workbench are not available.

However, it is possible to obtain this output by setting the IDL_BRIDGE_DEBUG environment variable. For example, if you set this environment variable to 1, you can see library load errors (on Windows), IDL execution errors, and output from IDL print commands. The appearance of debug information printed to stdout on Windows or UNIX depends upon the value set for the IDL_BRIDGE_DEBUG environment variable:

Value

Behavior

0

Turn off debug output

1

Turn on debug output, which includes output from library load errors, IDL execution errors, and PRINT statement output

To get additional Java-side diagnostics related to finding and loading the native libraries, define the IDL_LOAD_DEBUG parameter on the command line when starting a Java application, as follows:

java -DIDL_LOAD_DEBUG	<class-to-run>

1. Overview

ExecutorService is the central mechanism to execute tasks in Java. When we run our tasks in a thread pool backed by an ExecutorService, we must pay attention to exception handling. Remember that Java doesn’t require a method to handle or declare an unchecked RuntimeException, thus any code can throw a RuntimeException without us knowing. Upon getting an exception, we can log the error, notify a system, or take other diagnostic actions. In this tutorial, we’ll examine how we can handle exceptions thrown from the tasks running in an ExecutorService.

2. Default Behavior

If a thread terminates due to an uncaught exception, the JVM notifies the thread’s registered UncaughtExceptionHandler. If there is no registered handler, it prints the stack trace to System.err. 

public void executeThenThrowUnchecked() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1);

    executorService.execute(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after execute()");
    });

    executorService.shutdown();
}

Here, we’re first creating a thread pool by invoking newFixedThreadPool. Keep in mind that Executors.newFixedThread uses the DefaultThreadFactory class to create the worker threads. And DefaultThreadFactory doesn’t assign an UncaughtExceptionHandler to new threads. After we initialize the thread pool, we’re executing a Runnable task that throws a RuntimeException.

A sample run shows:

I will throw RuntimeException now.
Exception in thread "pool-1-thread-1" java.lang.RuntimeException: Planned exception after execute()
  at com.javabyexamples.java.concurrency.cancellation.exceptionhandling.DefaultBehavior.lambda$...
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

Here, the JVM prints the exception stack trace to the console, since the worker thread doesn’t have a registered UncaughtExceptionHandler.

2.1. Default Behavior with Callable

In the previous example, we’ve executed a Runnable task and the JDK tried to report the exception to a registered handler. However, if we submit a Callable task instead, ExecutorService returns a Future handle. The uncaught exception — if one occurs — is considered as a part of this Future. Thus the JDK doesn’t try to notify the handler:

public void submitThenThrowUnchecked() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1);

    final Future<Object> futureHandle = executorService.submit(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after submit()");
    });

    executorService.shutdown();
}

In this example, we’re submitting a Callable task instead of a Runnable. When we run the code, it doesn’t print the exception stack trace:

I will throw RuntimeException now.

We see the exception when we invoke the Future get method:

public void submitThenThrowUncheckedThenGet() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1);
    final Future<Object> future = executorService.submit(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after submit()");
    });

    try {
        future.get();
    } catch (InterruptedException e) {
        e.printStackTrace();
    } catch (ExecutionException e) {
        e.printStackTrace();
    }

    executorService.shutdown();
}

Here, when we invoke the get method, an ExecutionException will be thrown wrapping the original RuntimeException.

So we can conclude that even if a worker thread has an UncaughtExceptionHandler, the JDK won’t notify the handler for an uncaught exception that occurred in a Callable task.

3. Handle with UncaughtExceptionHandler

Next, we’ll register an UncaughtExceptionHandler to the worker threads. Remember that ExecutorService implementations use a ThreadFactory to create a new worker thread. For our purposes, we’ll create a new ThreadFactory implementation that sets an UncaughtExceptionHandler.

We’ll first define our handler:

public static class AppExceptionHandler implements UncaughtExceptionHandler {

    @Override
    public void uncaughtException(Thread t, Throwable e) {
        System.out.println("Uncaught Exception occurred on thread: " + t.getName());
        System.out.println("Exception message: " + e.getMessage());
    }
}

AppExceptionHandler simply logs the thread name and exception message.

Then we must implement a new ThreadFactory:

public static class AppThreadFactory implements ThreadFactory {

    @Override
    public Thread newThread(Runnable r) {
        final Thread thread = new Thread(r);
        thread.setUncaughtExceptionHandler(new AppExceptionHandler());
        return thread;
    }
}

AppThreadFactory sets a new AppExceptionHandler instance to every new thread invoking setUncaughtExceptionHandler.

Now that we have our thread factory, let’s use it when creating a thread pool:

public void executeThenThrowUnchecked() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1, new AppThreadFactory());
    
    executorService.execute(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after execute()");
    });

    executorService.shutdown();
}

We’re using the custom AppThreadFactory instead of DefaultThreadFactory. 

A sample run prints:

I will throw RuntimeException now.
Uncaught Exception occurred on thread: Thread-0
Exception message: Planned exception after execute()

There is no stack trace in the output since the thread has an assigned handler.

4. Handle with Wrapper Task

We’ll now investigate how we can handle an uncaught exception wrapping the original task. The previous UncaughtExceptionHandler approach applies to all threads and tasks in a thread pool. However, if we’re running different tasks in the same thread pool and they require different exception handling logic, this may not be optimal. Or we aren’t even allowed to set a handler because the task submission code is using a preconfigured pool. In these cases, we can wrap our original task in another Runnable or Callable. The wrapper class catches the exception and takes the appropriate action.

We’ll create a Runnable wrapper:

public static class CatchingRunnable implements Runnable {

    private final Runnable delegate;

    public CatchingRunnable(Runnable delegate) {
        this.delegate = delegate;
    }

    @Override
    public void run() {
        try {
            delegate.run();
        } catch (RuntimeException e) {
            System.out.println(e.getMessage()); // Log, notify etc...
            throw e;
        }
    }
}

CatchingRunnable contains a Runnable delegate. Notice the try/catch statement in the run method. If an exception occurs when running the delegate, we print the exception message. Though, this can be any other action to diagnose or notify the exception. Then we’re rethrowing the exception to not alter the original flow.

Let’s see the task submission code:

public void executeThenThrowUnchecked() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1);
    final CatchingRunnable catchingRunnable = new CatchingRunnable(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after execute()");
    });
    executorService.execute(catchingRunnable);

    executorService.shutdown();
}

Similar to the previous examples, we’re throwing a RuntimeException in our Runnable task.

When we run, it prints:

I will throw RuntimeException now.
Planned exception after execute()
Exception in thread "pool-1-thread-1" java.lang.RuntimeException: Planned exception after execute()
  at com.javabyexamples.java.concurrency.cancellation.exceptionhandling.WithWrappingTask.lambda$...
  at com.javabyexamples.java.concurrency.cancellation.exceptionhandling.WithWrappingTask$CatchingRunnable.run...
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

In the output, we see lines from multiple parts of the code. The first line comes from the original Runnable task. Then CatchingRunnable prints the exception message. Lastly, the JDK prints the stack trace since there is no registered UncaughtExceptionHandler.

5. Handle with Overriding afterExecute

Lastly, we’ll extend the ThreadPoolExecutor class to handle the uncaught exceptions. For this purpose, we’ll use the afterExecute hook method that ThreadPoolExecutor provides:

protected void afterExecute(Runnable r, Throwable t) { }

If the task completes normally, the Throwable argument is null. Otherwise, it contains the exception that caused the termination.

Now, we’ll extend ThreadPoolExecutor:

public static class MonitoringThreadPoolExecutor extends ThreadPoolExecutor {

    public MonitoringThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit,
      BlockingQueue<Runnable> workQueue) {
        super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);
    }

    @Override
    protected void afterExecute(Runnable r, Throwable t) {
        super.afterExecute(r, t);
        if(t != null){
            System.out.println("Exception message: " + t.getMessage());    
        }
    }
}

Here, we have the MonitoringThreadPoolExecutor class. In the afterExecute method, we print the exception message if one occurs.

Next, instead of using Executors, we’ll directly instantiate the thread pool:

public void executeThenThrowUnchecked() {
    final ExecutorService executorService = new MonitoringThreadPoolExecutor(1, 1, 0, TimeUnit.SECONDS,
      new LinkedBlockingQueue<>());
    executorService.execute(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after execute()");
    });

    executorService.shutdown();
}

A sample run prints:

I will throw RuntimeException now.
Exception message: Planned exception after execute()
Exception in thread "pool-1-thread-1" java.lang.RuntimeException: Planned exception after execute()
  at com.javabyexamples.java.concurrency.cancellation.exceptionhandling.WithOverridingAfterExecute.lambda$...
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

6. Summary

In this tutorial, we investigate how to handle an exception for tasks running in a thread pool. We first looked at the default exception handling behavior and the UncaughtExceptionHandler interface. Then we examined the wrapper tasks for more control on the handling logic. Then we extended the ThreadPoolExecutor class as a more general approach.

Lastly, check out the source code for all examples over on Github.

My application runs when run in command prompt
java -cp «resources;GlobasysLogger.jar» -Djava.library.path=lib com.globasyslogger.startup.StartGLogger

Above command works perfectly (It also has some dll )

When the same configured with wrapper, with following configuration

################################################
wrapper.java.command=java.exe

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar) Add class path elements as
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../../resources
wrapper.java.classpath.3=../../lib
wrapper.java.classpath.4=../../GlobasysLogger.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib
wrapper.java.library.path.2=../../lib

# Application parameters. Add parameters as needed starting from 1
wrapper.app.parameter.1=com.globasyslogger.startup.StartGLogger

wrapper.ntservice.account=.Administrator
wrapper.ntservice.password=123123
wrapper.debug=true
##################################################

when i run the command
wrapper.exe -c ..confwrapper.conf

It gives following log

#################################################
wrapper | —> Wrapper Started as Console
wrapper | Java Service Wrapper Community Edition 3.3.0
wrapper | Copyright (C) 1999-2008 Tanuki Software, Inc. All Rights Reserved.

wrapper | http://wrapper.tanukisoftware.org
wrapper |
wrapper | Using tick timer.
wrapperp | server listening on port 32000.
wrapper | Ping settings: wrapper.ping.interval=5, wrapper.ping.interval.logged=
1, wrapper.ping.timeout=30
wrapper | Launching a JVM…
wrapper | command: «D:Program FilesJavajre1.6.0binjava.exe» -Djava.library
.path=»../lib;../../lib» -classpath «../lib/wrapper.jar;../../resources;../../li
b;../../GlobasysLogger.jar» -Dwrapper.key=»oQ78ujCGsmQnJYkE» -Dwrapper.port=3200
0 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.debug=»TRU
E» -Dwrapper.pid=2400 -Dwrapper.version=»3.3.0″ -Dwrapper.native_library=»wrappe
r» -Dwrapper.cpu.timeout=»10″ -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.Wrapp
erSimpleApp com.globasyslogger.startup.StartGLogger
wrapper | JVM started (PID=6676)
jvm 1 | WrapperManager Debug: WrapperManager class initialized by thread: mai
n Using classloader: sun.misc.Launcher$AppClassLoader@11b86e7
jvm 1 | WrapperManager: Initializing…
jvm 1 | WrapperManager Debug: JVM #1
jvm 1 | WrapperManager Debug: Running a 32-bit JVM.
jvm 1 | WrapperManager Debug: Registering shutdown hook
jvm 1 | WrapperManager Debug: Using wrapper
jvm 1 | WrapperManager Debug: Load native library. One or more attempts may
fail if platform specific libraries do not exist. This is NORMAL and is only a
problem if they all fail.
jvm 1 | WrapperManager Debug: Loaded native library: wrapper-windows-x86-32
.dll
jvm 1 | WrapperManager Debug: Calling native initialization method.
jvm 1 | WrapperJNI Debug: Initializing WrapperManager native library.
jvm 1 | WrapperJNI Debug: Java Executable: D:Program FilesJavajre1.6.0bin
java.exe
jvm 1 | WrapperJNI Debug: Windows version: 5.1.2600
jvm 1 | WrapperManager Debug: Java Version : 1.6.0-b105 Java HotSpot(TM) Cl
ient VM
jvm 1 | WrapperManager Debug: Java VM Vendor : Sun Microsystems Inc.
jvm 1 | WrapperManager Debug:
jvm 1 | WrapperManager Debug: Control event monitor thread started.
jvm 1 | WrapperManager Debug: Startup runner thread started.
jvm 1 | WrapperManager Debug: WrapperManager.start(org.tanukisoftware.wrapper
.WrapperSimpleApp@bb6ab6, args[]) called by thread: main
jvm 1 | WrapperManager Debug: Communications runner thread started.
jvm 1 | WrapperManager Debug: Open socket to wrapper…Wrapper-Connection
jvm 1 | WrapperManager Debug: Opened Socket from 31000 to 32000
jvm 1 | WrapperManager Debug: Send a packet KEY : oQ78ujCGsmQnJYkE
jvm 1 | WrapperManager Debug: handleSocket(Socket[addr=/127.0.0.1,port=32000,
localport=31000])
wrapperp | accepted a socket from 127.0.0.1 on port 31000
wrapperp | read a packet KEY : oQ78ujCGsmQnJYkE
wrapper | Got key from JVM: oQ78ujCGsmQnJYkE
wrapperp | send a packet LOW_LOG_LEVEL : 1
wrapperp | send a packet PING_TIMEOUT : 30
wrapperp | send a packet PROPERTIES : (Property Values)
wrapper | Start Application.
wrapperp | send a packet START : start
jvm 1 | WrapperManager Debug: Received a packet LOW_LOG_LEVEL : 1
jvm 1 | WrapperManager Debug: LowLogLevel from Wrapper is 1
jvm 1 | WrapperManager Debug: Received a packet PING_TIMEOUT : 30
jvm 1 | WrapperManager Debug: PingTimeout from Wrapper is 30000
jvm 1 | WrapperManager Debug: Received a packet PROPERTIES : (Property Values
)
jvm 1 | WrapperManager Debug: Received a packet START : start
jvm 1 | WrapperManager Debug: calling WrapperListener.start()
jvm 1 | WrapperManager Debug: Waiting for WrapperListener.start runner thread
to complete.
jvm 1 | WrapperManager Debug: WrapperListener.start runner thread started.
jvm 1 | WrapperSimpleApp Debug: start(args) Will wait up to 2 seconds for the
main method to complete.
jvm 1 | WrapperSimpleApp Debug: invoking main method
jvm 1 | WrapperManager Debug: Send a packet START_PENDING : 5000
wrapperp | read a packet START_PENDING : 5000
wrapper | JVM signalled a start pending with waitHint of 5000 millis.
jvm 1 | WrapperManager Debug: Send a packet START_PENDING : 5000
jvm 1 | WrapperSimpleApp Debug: start(args) end. Main Completed=false, exitC
ode=null
jvm 1 | WrapperManager Debug: WrapperListener.start runner thread stopped.
jvm 1 | WrapperManager Debug: returned from WrapperListener.start()
jvm 1 | WrapperManager Debug: Send a packet STARTED :
wrapperp | read a packet START_PENDING : 5000
wrapper | JVM signalled a start pending with waitHint of 5000 millis.
wrapperp | read a packet STARTED :
wrapper | JVM signalled that it was started.
jvm 1 | WrapperManager Debug: Startup runner thread stopped.
wrapperp | send a packet PING : ping
jvm 1 | WrapperManager Debug: Received a packet PING : ping
jvm 1 | WrapperManager Debug: Send a packet PING : ping
wrapperp | read a packet PING : ping
jvm 1 | WrapperSimpleApp Debug: main method completed
jvm 1 | [thread 7196 also had an error]
jvm 1 | #
jvm 1 | # An unexpected error has been detected by Java Runtime Environment:
jvm 1 | #
jvm 1 | # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x77ea4d3a, pid=6676
, tid=4196
jvm 1 | #
jvm 1 | # Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode, sharing
)
jvm 1 | # Problematic frame:
jvm 1 | # C [RPCRT4.dll+0x34d3a]
jvm 1 | #
jvm 1 | # An error report file with more information is saved as hs_err_pid66
76.log
jvm 1 | #
jvm 1 | # If you would like to submit a bug report, please visit:
jvm 1 | # http://java.sun.com/webapps/bugreport/crash.jsp
jvm 1 | #
wrapper | JVM process exited with a code of 1, setting the wrapper exit code to
1.
wrapper | JVM exited unexpectedly.
wrapperp | server listening on port 32000.
wrapper | JVM was only running for 6 seconds leading to a failed restart count
of 1.
wrapper | Waiting 5 seconds before launching another JVM.
wrapper | CTRL-C trapped. Shutting down.
wrapper | wrapperStopProcess(0) called.
wrapper | <— Wrapper Stopped

###################################################

I have also attached the pid file

Понравилась статья? Поделить с друзьями:
  • Java virtual machine launcher ошибка как исправить на windows 10 unable to access jarfile
  • Java virtual machine launcher ошибка как исправить на windows 10 minecraft
  • Java virtual machine launcher ошибка как исправить майнкрафт
  • Java virtual machine launcher ошибка как исправить tlauncher
  • Java virtual machine launcher error unable to access jarfile javaw jar