Compatibility :	3.5.11
Editions :
Platforms :

Number of seconds to allow asynchronous startup operations to complete before the Wrapper continues with the startup process. Normally this should be set long enough for the operations to complete before continuing, but this timeout prevents very slow startups on some systems. On most systems these startup operations complete within 100 milliseconds.

Valid values are in the range of "1" to "3600" seconds, where "0" (zero) will not wait at all.

The default value is "2 seconds".

wrapper.startup_thread.timeout=2

Starting with Wrapper version 3.5.7, the Wrapper binaries on Windows are signed to prevent tampering and certify the origin of the binaries. In addition to the checks performed by the OS, the Wrapper also calls WinVerifyTrust to collect and report information about the certificate chain of the binary. The Wrapper also uses this information to shutdown the Wrapper if a corrupted binary is detected.

On most systems, the WinVerifyTrust call completes within a fraction of a second. On some systems however, Windows can take a long time to complete this operation. The delays appear to be related to attempts to access updated versions of the CRL file from Microsoft's server.

The default timeout of 2 seconds is short enough that the Wrapper startup will feel responsive, but long enough to allow the startup to complete in the majority of cases. If the timeout expires, the startup operations will continue in the background. Usually this will only result in the certificate chain being reported late in the log files, but it could also result in the Wrapper deciding to shutdown after the JVM has been launched if a corrupted binary is detected. For these reasons, it is not recommended that the timeout be set shorter than the default 2 seconds.

• 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 )