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.

Strarting 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.

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

WARNING - Unable to load native library 'wrapper' for class WrapperManager.
          System signals will not be handled correctly.

As of Wrapper version 2.2.9, this error message was improved. You will now see something like the following (Depending on your platform of course):

WARNING - Unable to load native library 'wrapper' because the
          file 'wrapper.dll' could not be located in the following
          java.library.path:
            C:\SourceForge\wrapper\bin\..\lib
          Please see the documentation for the wrapper.java.library.path
          configuration property.
          System signals will not be handled correctly.

On Windows 2000 or NT, you will see the following error message if you attempt to install a service when logged in as a user without Administrator privileges.

OpenSCManager failed - access denied.

For this solution, contact your system administrator and beg them to install the service for you. Easy if that is you.

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.

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 (WinNT\System32).

If you call System.exit() in your application, then 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.

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 version 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

I 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 version 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. I am not sure how many people are still using 1.2.x JVMs. But if it is still fairly common, I may reconsider the above policy and look into what it will take to get the releases built using an older JVM.

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 like 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.log 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.

The problem is that you might set the wrapper.java.command property to a batch file rather than directly to the 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. When the child, Java exits, it immediately 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

This proplem 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

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 which JBoss is using. More information about this can be found on the JMX Page.

wrapper  | A signature was found in "C:\wrapper-windows-x86-32-3.5.7-pro\bin\wra
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 which 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 occures 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.

Using 'mmc' or 'certmgr.msc', please confirm the certificate installation:

• "AddTrust External CA Root" should be installed under "Trusted Root Certificate Authorities\Certificates"

• "COMODO RSA Certification Authority" and "COMODO RSA Code Signing" should be installed under "Intermediate Certification Authorities\Certificates". 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 properties window accessible from the context menu.

• "UTN-USERFirst-Object" should be installed under "Third Parties Root Certification Authorities\Certificates".

If those certificates are not present our outdated, they can be downloaded from the Comodo website.

• SHA-2 certificates (addtrustexternalcaroot.crt, comodorsaaddtrustca.crt and comodorsacodesigningca.crt) are suitable when using Wrapper 3.5.28 and above:
  https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/985/108/code-signing-sha-2

• SHA-1 certificates (addtrustexternalcaroot.crt, utnaddtrustobject_ca.crt and comodocodesigningca2.crt) are also available as legacy files (for Wrapper version 3.5.27 or lower):
  https://support.comodo.com/index.php?/Default/Knowledgebase/List/Index/93/code-signing

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, 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 tight 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 shutdown if the reason, 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.

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.

The Wrapper itself does not place any restrictions on the number of Wrapper instances which 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 which causes problems is the Desktop Heap. Please see the Solving Desktop Heap Problems page for more information.

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/sh.script.in (you have probably renamed this file).

OS_VER=`sw_vers | grep 'ProductVersion:' | grep -o '[0-9]*\.[0-9]*\.[0-9]*'`

OS_VER=`sw_vers | grep 'ProductVersion:' | grep -o '[0-9]*\.[0-9]*\.[0-9]*\|[0-9]*\.[0-9]*'`

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.