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 graphics 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 which 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".

	Sun's Documentation
	Another good place to look is the Performance Documentation for the Java HotSpot VM page on Sun's site. In addition, there was a very informative JDC Tech Tip talking about "Garbage Collection" issues.

Strarting with version 3.0.5 of the Java Service Wrapper, 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 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.

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 (wrapper.dll on Windows and libwrapper.so on Unix systems). You should place the library file in the specified directory or change the property to point to the directory where the library is located.

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.

Most of the features of the Wrapper will work with version 1.2.x of JVMs so the JVM is included on the list of supported 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 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 | Java Virtual Machine 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 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 Wrapper Professional edition has the ability to do exactly that:Wrapper Event Configuration

On system-V based systems the wrapper will not start during boot when the RUN_AS_USER has not configured a shell in /etc/passwd.
Two possible solutions:
1) Assign a usable shell (e.g. /etc/bash) to the account used.
2) Change line 329 of the init file from [su -m $RUN_AS_USER -c "\"$REALPATH\" $2"] to [su -s /bin/sh -m $RUN_AS_USER -c "\"$REALPATH\" $2"] (without the square brackets)
Note: This was detected and only tested on CentOS 5.3

Steven

It would be useful for people who do not have java beans and reflection on their minds to alert them that the class in which the main() will be invoked must be declared as a public class or you will receive the following error in the log:
WrapperSimpleApp: java.lang.IllegalAccessException: Class org.tanukisoftware.wrapper.WrapperSimpleApp can not access a member of class com.x.y.z with modifiers "public static"

Hi,

I'm trying to run JBoss as a service using the wrapper and it doesn't work with the latest releases of the Java SDK (I've tried 1.6.0_10 and 1.6.0_11). I get the following error message in the wrapper log file:

STATUS | wrapper | 2009/01/12 16:28:30 | Launching a JVM...
INFO | jvm 4 | 2009/01/12 16:28:30 | Error occurred during initialization of VM
INFO | jvm 4 | 2009/01/12 16:28:30 | Could not reserve enough space for code cache
ERROR | wrapper | 2009/01/12 16:28:30 | JVM exited while loading the application.

However, if I use an older version of Java (1.6.0_03) then everything works fine.

Anyone else with the same problem?

My Application will not start if I set wrapper.java.maxmemory=1536, however it will work if not using the Wrapper. Any help is appreciated.

That worked Leif, thanks! :)

And thank you so much for creating this awesome package! It's the best way to create Java daemons that I've found.

Zach. Sorry, this is a known bug in the shell script for OSX. It has been fixed for the next release. In the mean time, please grab the latest shell script from SVN:
http://wrapper.svn.sourceforge.net/viewvc/*checkout*/wrapper/trunk/wrapper/src/bin/sh.script.in

I followed the Method 1 tutorial with a simple app of mine that just prints a '.' every second in a while(true) loop. I can start the app fine using:

bin/daemontest start

But running this:

bin/daemontest stop

Produces this:

Stopping Daemon Test...
ps: args: keyword not found
ps: no valid keywords
Removed stale pid file: /Users/zcox/dev/workspace/DaemonTest/bin/./daemontest.pid
Daemon Test was not running.

And my app keeps on running and can't be stopped unless I open the Activity Monitor and kill the wrapper process (I'm on Mac OS X 10.4).

Any ideas why the app can't be stopped? I did chmod -R 777 on the bin directory, and verified that the daemontest.pid file does get written there properly.

Update: I just verified that the value in daemontest.pid is the same as the Process ID shown in Activity Monitor for the wrapper process.

Puria,
As the exception says. It looks like your HTTPS certificate has expired. You need to renew it.

Cheers,
Leif

STATUS | wrapper | 2007/09/12 22:26:21 | --> Wrapper Started as Service
STATUS | wrapper | 2007/09/12 22:26:22 | Launching a JVM...
INFO | jvm 1 | 2007/09/12 22:26:22 | Wrapper (Version 3.1.2) http://wrapper.tanukisoftware.org
INFO | jvm 1 | 2007/09/12 22:26:22 |
INFO | jvm 1 | 2007/09/12 22:26:22 | javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateExpiredException: NotAfter: Wed Sep 12 14:58:20 EDT 2007
INFO | jvm 1 | 2007/09/12 22:26:22 | at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(Unknown Source)

Why is this error occuring?? Any ideas?? We need to run HTTPS, but received this error today. This was working fine for months previously. Additionally, when I use HTTP the wrapper works fine.

The maximum number of invocations can be set with the wrapper.max_failed_invocations property.

Please help me appreciate if there is a configurable-property or equivalent to set "n"-number of failed launches in a row - instead of the default "5"?

wrapper | JVM exited while loading the application.
wrapper | There were 5 failed launches in a row, each lasting less than 300 seconds. Giving up.
wrapper | There may be a configuration problem: please check the logs.

I had some trouble getting this to start, due to my own lack of any knowledge about running Windows services (I'm running a "method 1" install under Win XP Pro), but I think it's worth sharing:

You *cannot* start the wrapper as a service by calling
. WRAPPER_HOMEinwrapper.exe -s ..conf
from the command line. The system will give you an error reading
. Calling StartServiceCtrlDispatcher...
. StartServiceControlDispatcher failed!

The correct command line syntax requires invoking NET START:
. net start %Appname%
Where %Appname% is the name under which you've registered the service, determined in wrapper.conf as wrapper.ntservice.name and wrapper.ntservice.displayname (calling either will work).

The reason I was trying this in the first place is that I could get the service to run as a console (-c handle) but could not get it to start from the Windows Services control. (That problem, as suggested above, was a mistyped classpath in the wrapper.conf file.)

This failure doesn't write anything to the logfile; perhaps it should?