Le Wrapper tentera d'obtenir un verrou en lecture/écriture sur le fichier lors de l'ouverture du fichier de commandes. Une fois ouvert, toutes les commandes seront exécutées dans l'ordre puis le fichier sera supprimé une fois les commandes terminées.

Les processus externes qui créent des fichiers de commandes doivent toujours ouvrir le fichier de commandes en mode « append ». Ainsi, si le fichier n'existe pas, il sera créé, mais s'il existe déjà, les nouvelles commandes seront ajoutées à la fin.

Le Wrapper tentera plusieurs fois, pendant une seconde au maximum, d'ouvrir le fichier de commandes une fois qu'il a été déterminé qu'il existe. Cela permet d'éviter les problèmes pendant qu'un autre processus est en train d'écrire le fichier. Si le fichier reste verrouillé plus d'une seconde, un message d'avertissement apparaîtra dans le fichier journal. Cela n'affectera pas le fonctionnement du Wrapper, mais pour éviter les avertissements, il est important que le fichier soit verrouillé le plus brièvement possible.

Le fichier est formaté comme un fichier texte avec une seule commande par ligne. Les commandes possibles sont :

• STOP {EXIT_CODE} :
  

  Demande au Wrapper de s'arrêter proprement. Le {EXIT_CODE} optionnel peut être utilisé pour spécifier le exitCode lorsque le Wrapper s'arrête effectivement.

• RESTART :
  

  Demande au Wrapper de redémarrer sa JVM. Cela peut être utilisé en combinaison avec la propriété wrapper.restart.reload_configuration pour que le Wrapper recharge sa configuration puis lance une nouvelle JVM reflétant les modifications. Ignoré si la JVM n'est pas en cours d'exécution.

• PAUSE :
  

  Demande que le Wrapper soit mis en pause. Pris en charge uniquement lorsque la propriété wrapper.pausable est TRUE.

• RESUME :
  

  Demande que le Wrapper soit repris. Pris en charge uniquement lorsque la propriété wrapper.pausable est TRUE.

• SUSPEND_TIMEOUTS {TIME} (Depuis la version 3.5.40) (Éditions Standard et Professionnelle) :
  

  Indique au Wrapper de suspendre tous les délais d'attente utilisés lorsque la JVM ne répond pas. {TIME} spécifie le nombre de secondes pendant lesquelles les délais d'attente doivent être suspendus, et doit être compris dans la plage 1-3600 (1 h). Cela peut être utilisé si l'application Java doit effectuer une tâche bloquante de longue durée et éviter que le Wrapper considère l'application comme ne répondant pas.

  Les délais d'attente peuvent également être suspendus via des propriétés d'action ou la méthode Java WrapperManager.suspendTimeouts().

  Si plusieurs demandes de suspension des délais d'attente sont effectuées, le nombre de secondes spécifié par chaque demande ne sera pas additionné. À la place, le nouveau délai spécifié replacera le temps de suspension restant s'il est plus long, et sera ignoré dans le cas contraire.

• RESUME_TIMEOUTS (Depuis la version 3.5.40) (Éditions Standard et Professionnelle) :
  

  Indique au Wrapper de reprendre tous les délais d'attente précédemment suspendus.

  Les délais d'attente peuvent également être repris via d'autres propriétés d'action ou la méthode Java WrapperManager.resumeTimeouts().

• USER_{n} (Depuis la version 3.5.57) (Édition Professionnellel) :
  

  Indique au Wrapper de déclencher un événement utilisateur.

  Le composant « {n} » du nom de l'événement est un entier quelconque compris dans la plage 1-32767.

• DUMP :
  

  Demande au Wrapper de faire produire un dump de threads par la JVM. Les résultats peuvent être consultés dans le fichier journal du Wrapper. Ignoré si la JVM n'est pas en cours d'exécution.

• GC (Depuis la version 3.5.7) :
  

  Demande à la JVM d'effectuer immédiatement un cycle complet de ramasse-miettes (garbage collection). Sachez que le faire fréquemment peut affecter les performances de la JVM car un cycle complet entraînera souvent le gel de tous les threads pendant toute la durée du GC. Ignoré si la JVM n'est pas en cours d'exécution.

• CONSOLE_LOGLEVEL {LOG_LEVEL} :
  

  Modifie le niveau de journalisation de la console du Wrapper.

• LOGFILE_LOGLEVEL {LOG_LEVEL} :
  

  Modifie le niveau de journalisation du fichier journal du Wrapper.

• SYSLOG_LOGLEVEL {LOG_LEVEL} :
  

  Modifie le niveau de journalisation du syslog ou de l'Event Log du Wrapper.

Des commandes de test supplémentaires sont également disponibles si et seulement si la propriété wrapper.commandfile.enable_tests est TRUE. Ces commandes sont désactivées par défaut par mesure de sécurité, car certaines d'entre elles pourraient causer des problèmes de sécurité ou de stabilité pour le Wrapper et votre application.

Les commandes de test possibles sont :

• ACCESS_VIOLATION (Depuis la version 3.5.2) :
  

  Provoque le plantage du processus Wrapper lui-même, qui ne parvient donc pas à s'arrêter proprement. Lorsque cela se produit, la JVM devrait immédiatement détecter que le Wrapper a disparu et s'arrêter elle-même proprement. Rien après la violation d'accès ne sera conservé dans le fichier journal du Wrapper. Cela est utile pour tester le comportement du Wrapper, de la JVM et des systèmes externes si le Wrapper venait à planter.

• CLOSE_BACKEND (Depuis la version 3.5.26) :
  

  Provoque la fermeture immédiate de la connexion backend avec la JVM. Cela est utile pour tester la capacité de la JVM à se reconnecter au Wrapper. Ignoré si la JVM n'est pas en cours d'exécution.

• CLOSE_SOCKET (Depuis la version 3.5.0) :
  

  Provoque la fermeture immédiate du socket backend avec la JVM. Cela est utile pour tester la capacité de la JVM à se reconnecter au Wrapper. Ignoré si la JVM n'est pas en cours d'exécution.

  Depuis la version 3.5.26, il s'agit d'un alias de « CLOSE_BACKEND ».

• PAUSE_LOGGER {seconds} (Depuis la version 3.5.11) :
  

  Provoque la pause par le Wrapper de la prochaine ligne de sortie du journal pendant le nombre de secondes spécifié. Cela est utile pour tester la capacité du Wrapper et de la JVM à gérer les retards dans le code de journalisation. Le paramètre {seconds} peut être compris dans la plage de « 1 » à « 3600 », ou « 0 » (zéro) pour une durée indéfinie. Cette commande est désactivée par mesure de sécurité sauf si wrapper.commandfile.enable_tests est TRUE.

• PAUSE_THREAD {THREAD} {TIME} (Depuis la version 3.5.8) :
  

  Provoque la pause du thread Wrapper spécifié avec le paramètre suivant pendant une durée fixe. Cela est utile pour tester le comportement du Wrapper dans des situations de charge élevée qui pourraient priver un ou plusieurs threads du Wrapper de CPU. La cause la plus courante de longues pauses est des temps d'attente d'E/S élevés lors d'opérations telles que la journalisation.

  Paramètre {THREAD} obligatoire :

  Le paramètre {THREAD} est requis pour la valeur de propriété PAUSE_THREAD, et peut avoir l'une des valeurs suivantes :

  • MAIN :
    

    Le thread principal du Wrapper, y compris la surveillance et le ping du processus JVM.

  • TIMER :
    

    Le thread de minuterie qui existe si la propriété wrapper.use_system_time est FALSE.

  • JAVAIO :
    

    Le thread d'E/S Java qui existe si la propriété wrapper.javaio.use_thread est TRUE.

  • EVENT :
    

    Le thread utilisé pour traiter toutes les actions d'événement. Disponible uniquement dans l'édition Professional.

  Paramètre {TIME} optionnel :

  Le paramètre optionnel {TIME} pour la valeur de propriété PAUSE_THREAD est utilisé pour spécifier le nombre de secondes pendant lesquelles le thread sera retardé. Les valeurs valides sont « -1 », ou « 0 » (zéro) à « 3600 » secondes. Une valeur de « -1 » fera durer la pause indéfiniment. Une valeur de « 0 » (zéro) n'aura aucun effet, et les valeurs plus élevées mettront en pause pendant le nombre de secondes spécifié. La valeur par défaut est « -1 ».

  Pendant que le thread MAIN est en pause, le Wrapper ne répondra pas ; il peut donc être nécessaire de tuer de force le processus du Wrapper pour rétablir le fonctionnement avant l'expiration du temps de pause.