Compatibility :	1.0.0
Editions :
Platforms :

Number of seconds to allow between the time that the Wrapper launches the JVM process and the time that the JVM side of the Wrapper responds that the application has started. Setting this property value to "0" (zero) means never time out.

The default value is "30 seconds".

wrapper.startup.timeout=30

Problems?

If you are experiencing timeout problems as your application is starting up, the most common cause is a misconfiguration. Please verify that the WrapperManager is indeed being started. You should see the following output in the console when you launch the Wrapper.

wrapper  | --> Wrapper Started as Console
wrapper  | Java Service Wrapper Professional Edition 64-bit 3.x.x
wrapper  |   Copyright (C) 1999-2010 Tanuki Software, Ltd.  All Rights Reserved.
wrapper  |     http://wrapper.tanukisoftware.org
wrapper  |   Licensed to Acme, Inc.
wrapper  |
wrapper  | Launching a JVM...
jvm 1    | WrapperManager: Initializing...

If you do not see the Wrapper version displayed, then the WrapperManager is not being launched. Please make sure that you have read over the Summary of Integration Methods section to check the correct configuration. If the configuration looks correct, then try enabling DEBUG level log output to try and narrow in on the problem.

If the Wrapper version is being displayed, but the Wrapper is still timing out on startup, then it is most likely being caused by one of two reasons.

The first possibility is that the start method call is not returning. This should not be an issue if you are using the WrapperSimpleApp, WrapperStartStopApp or WrapperJarApp classes to launch your application. If you are implementing the WrapperListener however, please verify that the start method is indeed returning upon completion. You should be able to see this with DEBUG output enabled.

The other possibility is that the startup method is simply taking a while to complete. In this case, it may be necessary to extend the default startup timeout. Try setting to "300 seconds" (5 minutes) and see if that makes the problem go away.

It is best to choose a value which is long enough to let the application start reliably, but short enough that the Wrapper will react as quickly as possible in the event of an actual JVM hang.

WrapperManager.signalStarting(n) :

If the start procedure sometimes takes a long time, one alternative to setting a long timeout is to periodically call the WrapperManager.signalStarting(n) method. This method lets the Wrapper know that the JVM is alive and the application's startup is going well. The report will be repeated as many times as needed. Therefore, that additional time is required, and it may take much longer time on the startup.

If the main class configured with the wrapper.java.mainclass property does not correctly initialize the Wrapper's WrapperManager class, then the startup will fail with the following message even though the application appears to have been started:

------------------------------------------------------------------------
Advice:
The Wrapper consists of a native component as well as a set of classes
which run within the JVM that it launches.  The Java component of the
Wrapper must be initialized promptly after the JVM is launched or the
Wrapper will timeout, as just happened.  Most likely the main class
specified in the Wrapper configuration file is not correctly initializing
the Wrapper classes:
    com.myapp.Main
While it is possible to do so manually, the Wrapper ships with helper
classes to make this initialization processes automatic.
Please review the integration section of the Wrapper's documentation
for the various methods which can be employed to launch an application
within the Wrapper:
    http://wrapper.tanukisoftware.org/doc/english/integrate.html
------------------------------------------------------------------------

As the message states, this is a configuration problem and can be resolved by following the instructions for one of the documented Integration Methods.

• wrapper.cpu.timeout (2.2.8)

  Configures the number of seconds without CPU before the JVM sends a warning and extend timeouts.

• wrapper.max_hostid_timeout (3.4.0) ( Std/Pro )

• wrapper.logfile.close.timeout (3.5.21)

  Controls the number of seconds at which the log file should close after the last log entry.

• wrapper.logfile.flush.timeout (3.5.21)

  Configures the interval in seconds at which the Wrapper flushes all outputs to the log file.

• wrapper.logfile.inactivity.timeout (3.2.0, deprecated as of 3.5.21)

  Controls the number of seconds at which the log file should close after the last log entry.

• wrapper.ping.timeout (1.0.0)

  Configures the number of seconds to allow between two ping responses coming from the JVM.

• wrapper.startup_thread.timeout (3.5.11)

  Configures the number of seconds to allow asynchronous startup operations to be completed.

• wrapper.startup.timeout (1.0.0)

  Configures the number of seconds to allow between the time the Wrapper launches the JVM and the time the JVM responds that the application has started.

• wrapper.shutdown.timeout (2.2.7)

  Configures the number of seconds to allow between the time the Wrapper asks the JVM to shutdown and the time the JVM responds that it is stopping.

• wrapper.jvm_exit.timeout (2.2.8)

  Configures the number of seconds to allow between the time the JVM reports it is stopped and the time the JVM process actually terminates.

• wrapper.jvm_cleanup.timeout (3.4.0)

  Configures the number of seconds allowed for the Wrapper to clean up child processes after the JVM has been shutdown.

• wrapper.jvm_terminate.timeout (3.5.18)

  Configures the number of seconds to allow from the time that the Wrapper asks the system to forcibly terminate the JVM until it confirms that the process actually stopped.

• wrapper.event.<event_name>.command.block.timeout (3.3.0) ( Pro )

  Configures how long the Wrapper will wait for a configured event to complete.

• wrapper.event.<event_name>.email.receive.timeout (3.3.2) ( Pro )
• wrapper.event.<event_name>.email.send.timeout (3.3.2) ( Pro )

• wrapper.disable_restarts (3.2.0)

  Disables all JVM restarts by the Wrapper, including restarts caused by errors and requested restarts from within the JVM.

• wrapper.disable_restarts.automatic (3.3.4)

  Disables automatic JVM restarts by the Wrapper, including restarts when the JVM crashes or exits unexpectedly.

• wrapper.max_failed_invocations (2.2.8)

  Configures the number of times the Wrapper will attempt to restart the JVM.

• wrapper.successful_invocation_time (2.2.8)

  Configures the minimum amount of time that the Java application must remain running to be considered as successfully started.

• wrapper.startup.timeout (1.0.0)

  Configures the number of seconds to allow between the time the Wrapper launches the JVM and the time the JVM responds that the application has started.