Compatibilité :	1.0.0
Éditions :
Plateformes :

Nombre de secondes à autoriser entre le moment où le Wrapper lance le processus JVM et le moment où le côté JVM du Wrapper répond que l'application a démarré. Définir la valeur de cette propriété à « 0 » (zéro) signifie qu'il n'y a jamais de délai d'attente.

La valeur par défaut est « 30 secondes ».

wrapper.startup.timeout=30

Problèmes ?

Si vous rencontrez des problèmes de délai d'attente lors du démarrage de votre application, la cause la plus fréquente est une mauvaise configuration. Veuillez vérifier que le WrapperManager est bien démarré. Vous devriez voir la sortie suivante dans la console lorsque vous lancez le 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...

Si vous ne voyez pas s'afficher la version du Wrapper, alors le WrapperManager n'est pas lancé. Veuillez vous assurer d'avoir lu la section Résumé des méthodes d'intégration pour vérifier la configuration correcte. Si la configuration semble correcte, essayez d'activer la sortie de journal de niveau DEBUG pour tenter de cerner le problème.

Si la version du Wrapper s'affiche, mais que le Wrapper expire toujours au démarrage, cela est très probablement dû à l'une des deux raisons suivantes.

La première possibilité est que l'appel de la méthode start ne retourne pas. Cela ne devrait pas poser de problème si vous utilisez les classes WrapperSimpleApp, WrapperStartStopApp ou WrapperJarApp pour lancer votre application. Si vous implémentez cependant WrapperListener, veuillez vérifier que la méthode start retourne bien une fois terminée. Vous devriez pouvoir le constater avec la sortie DEBUG activée.

L'autre possibilité est que la méthode de démarrage prenne simplement un certain temps à se terminer. Dans ce cas, il peut être nécessaire d'augmenter le délai d'attente de démarrage par défaut. Essayez de le définir à « 300 secondes » (5 minutes) et voyez si le problème disparaît.

Il est préférable de choisir une valeur suffisamment longue pour permettre à l'application de démarrer de manière fiable, mais suffisamment courte pour que le Wrapper réagisse aussi rapidement que possible en cas de blocage réel de la JVM.

WrapperManager.signalStarting(n) :

Si la procédure de démarrage prend parfois beaucoup de temps, une alternative à la définition d'un long délai d'attente consiste à appeler périodiquement la méthode WrapperManager.signalStarting(n). Cette méthode informe le Wrapper que la JVM est en vie et que le démarrage de l'application se déroule bien. Le rapport sera répété autant de fois que nécessaire. Par conséquent, ce temps supplémentaire est requis, et le démarrage peut prendre beaucoup plus de temps.

Si la classe principale configurée avec la propriété wrapper.java.mainclass n'initialise pas correctement la classe WrapperManager du Wrapper, alors le démarrage échouera avec le message suivant même si l'application semble avoir été démarrée :

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

Comme l'indique le message, il s'agit d'un problème de configuration qui peut être résolu en suivant les instructions de l'une des méthodes d'intégration documentées.

• wrapper.cpu.timeout (2.2.8)

  Configure le nombre de secondes sans CPU avant que la JVM n'envoie un avertissement et n'étende les délais d'attente.

• wrapper.max_hostid_timeout (3.4.0) ( Standard/Professionnel )

• wrapper.logfile.close.timeout (3.5.21)

  Contrôle le nombre de secondes au bout desquelles le fichier journal doit se fermer après la dernière entrée de journal.

• wrapper.logfile.flush.timeout (3.5.21)

  Configure l'intervalle en secondes auquel le Wrapper vide toutes les sorties vers le fichier journal.

• wrapper.logfile.inactivity.timeout (3.2.0, obsolète depuis 3.5.21)

  Contrôle le nombre de secondes au bout desquelles le fichier journal doit se fermer après la dernière entrée de journal.

• wrapper.ping.timeout (1.0.0)

  Configure le nombre de secondes autorisées entre deux réponses de ping provenant de la JVM.

• wrapper.startup_thread.timeout (3.5.11)

  Configure le nombre de secondes accordées pour que les opérations de démarrage asynchrones se terminent.

• wrapper.startup.timeout (1.0.0)

  Configure le nombre de secondes autorisées entre le moment où le Wrapper lance la JVM et le moment où la JVM répond que l'application a démarré.

• wrapper.shutdown.timeout (2.2.7)

  Configure le nombre de secondes autorisées entre le moment où le Wrapper demande à la JVM de s'arrêter et le moment où la JVM répond qu'elle est en train de s'arrêter.

• wrapper.jvm_exit.timeout (2.2.8)

  Configure le nombre de secondes autorisées entre le moment où la JVM signale qu'elle est arrêtée et le moment où le processus JVM se termine réellement.

• wrapper.jvm_cleanup.timeout (3.4.0)

  Configure le nombre de secondes accordées au Wrapper pour nettoyer les processus enfants après l'arrêt de la JVM.

• wrapper.jvm_terminate.timeout (3.5.18)

  Configure le nombre de secondes autorisées à partir du moment où le Wrapper demande au système de terminer de force la JVM jusqu'à ce qu'il confirme que le processus s'est réellement arrêté.

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

  Configure la durée pendant laquelle le Wrapper attendra qu'un événement configuré se termine.

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

• wrapper.disable_restarts (3.2.0)

  Désactive tous les redémarrages de la JVM par le Wrapper, y compris les redémarrages causés par des erreurs et les redémarrages demandés depuis la JVM.

• wrapper.disable_restarts.automatic (3.3.4)

  Désactive les redémarrages automatiques de la JVM par le Wrapper, y compris les redémarrages lorsque la JVM plante ou se termine de façon inattendue.

• wrapper.max_failed_invocations (2.2.8)

  Configure le nombre de fois que le Wrapper tentera de redémarrer la JVM.

• wrapper.successful_invocation_time (2.2.8)

  Configure la durée minimale pendant laquelle l'application Java doit rester en cours d'exécution pour être considérée comme démarrée avec succès.

• wrapper.startup.timeout (1.0.0)

  Configure le nombre de secondes autorisées entre le moment où le Wrapper lance la JVM et le moment où la JVM répond que l'application a démarré.