Der Wrapper versucht, eine Lese-/Schreib-Datensperre auf die Datei zu setzen, sobald die Befehlsdatei geöffnet wird. Sobald diese geöffnet wurde, werden alle Befehle in Reihenfolge ausgeführt und dann wird die Datei nach Ausführung aller Befehle gelöscht.

Externe Prozesse, die Befehlszeile erstellen, sollten stets die Befehlszeile in "append"-Modus öffnen. Auf diese Weise wird die Datei, sollte sie noch nicht existieren, neu erstellt werden, aber, wenn sie bereits existiert, dann werden alle neuen Befehle einfach angehängt werden.

Der Wrapper versucht mehrmals für bis zu einer Sekunde, die Befehlsdatei zu öffnen, sobald es festgestellt wurde, dass diese existiert. Dies wird getan, um Probleme zu vermeiden, während ein anderer Prozess versucht, die Datei zu schreiben. Wenn die Datei für mehr als eine Sekunde gesperrt bleibt, wird eine Warnmeldung in der Logdatei erscheinen. Dies wird den Betrieb des Wrappers nicht beeinträchtigen, aber um Warnmeldungen zu vermeiden, ist es wichtig, dass die Datei so kurz wie möglich gesperrt wird.

Die Datei wird mit einem einzelnen Befehl auf jeder Zeile als eine Textdatei formatiert. Mögliche Befehle beinhalten:

• STOP {EXIT_CODE} :
  

  Anforderungen, dass der Wrapper sich korrekt beendet. Der optionale {EXIT_CODE} kann genutzt werden, um den exitCode zu spezifizieren, wann sich der Wrapper tatsächlich beendet.

• RESTART :
  

  Fordert den Wrapper auf, seine JVM neu zu starten. Dies kann in Kombination mit der wrapper.restart.reload_configuration Eigenschaft genutzt werden, um zu bewirken, dass der Wrapper seine Konfiguration neu lädt und dann eine neue JVM startet, um die Änderungen widerzugeben. Wird ignoriert, wenn die JVM nicht läuft.

• PAUSE :
  

  Fordert an, dass der Wrapper unterbrochen wird. Wird nur unterstützt, wenn der Wrapper als ein Windows-Dienst ausgeführt wird und die wrapper.pausable Eigenschaft mit WAHR gesetzt ist.

• RESUME :
  

  Fordert an, dass der Wrapper seine Ausführung fortsetzt. Wird nur unterstützt, wenn der Wrapper als ein Windows-Dienst ausgeführt wird und die wrapper.pausable Eigenschaft mit WAHR gesetzt ist.

• DUMP :
  

  Fordert den Wrapper auf, die JVM zu veranlassen, einen Thread-Dump zu erstellen. Die Ergebnisse können in der Logdatei des Wrappers eingesehen werden. Wird ignoriert, wenn die JVM nicht läuft.

• GC (Since version 3.5.7) :
  

  Fordert die JVM auf, einen sofortigen, vollständigen Speicherbereinigungsdurchlauf durchzuführen. Bitte seien Sie sich bewusst, dass wiederholtes Tun die Leistung der JVM beeinträchtigen kann, da ein vollständiger Durchlauf oft dazu führt, dass alle Threads für dessen Dauer angehalten werden. Wird ignoriert, wenn die JVM nicht läuft.

• CONSOLE_LOGLEVEL {LOG_LEVEL} :
  

  Ändert die Logebene der Konsole des Wrappers.

• LOGFILE_LOGLEVEL {LOG_LEVEL} :
  

  Ändert die Logebene der Logdatei des Wrappers.

• SYSLOG_LOGLEVEL {LOG_LEVEL} :
  

  Ändert die Logebene des syslogs oder des Eventlogs des Wrappers.

Zusätzliche Testbefehle sind auch verfügbar, wenn und nur dann, wenn die wrapper.commandfile.enable_tests Eigenschaft WAHR ist. Diese Befehle sind aus Sicherheitsgründen standardmäßig deaktiviert, da einige von ihnen Sicherheits- oder Stabilitätsprobleme für den Wrapper und Ihre Anwendung verursachen können.

Mögliche Testbefehle beinhalten:

• ACCESS_VIOLATION (Since version 3.5.2) :
  

  bewirkt, dass der Wrapper-Prozess selbst abstürzt und das fehlerfreie Beenden somit misslingt. Wenn dies passiert, sollte die JVM sofort erkennen, dass der Wrapper nicht mehr existiert und sich sich selbst fehlerfrei beenden. Nach der Zugriffsverletzung werden in der Wrapper Logdatei keinerlei Daten gespeichert werden. Dies ist nützlich, um zu testen, wie sich der Wrapper, die JVM und externe Systeme verhalten, wenn der Wrapper abgestürzt war.

• CLOSE_BACKEND (Since version 3.5.26) :
  

  bewirkt, dass die Backend-Verbindung mit der JVM sofort beendet wird. Dies ist nützlich, um die Fähigkeit der JVM für einen erneuten Verbindungsaufbauz mit dem Wrapper zu testen. Wird ignoriert, wenn die JVM nicht läuft.

• CLOSE_SOCKET (Since version 3.5.0) :
  

  bewirkt, dass das Back-End Socket mit der JVM umgehend geschlossen wird. Dies ist nützlich, um die Fähigkeit der JVM für einen erneuten Verbindungsaufbau mit dem Wrapper zu testen. Wird ignoriert, wenn die JVM nicht läuft.

  Seit Version 3.5.26 ist dies ein Alias für "CLOSE_BACKEND".

• PAUSE_LOGGER {seconds} (Since version 3.5.11) :
  

  Bewirkt, dass der Wrapper, die Ausgabe der nächsten Zeile der Logausgabe für ein paar Sekunden unterbricht. Dies ist nützlich, um die Fähigkeit des Wrappers und der JVM bezüglich eines erneuten Verbindungsaufbaus mit dem Wrapper zu testen. Die {Sekunden}-Parameter können im Bereich zwischen "1" und"3600", oder "0" (Null) für unbegrenzt liegen. Dieser Befehl ist aus Sicherheitsgründen deaktiviert - mit Ausnahme, wenn wrapper.commandfile.ena+ble_tests gleich WAHR ist.

• PAUSE_THREAD {THREAD} {TIME} (Since version 3.5.8) :
  

  Bewirkt, dass die spezifizierte Wrapper-Thread mit den folgenden Parametern für einen festgelegten Zeitabschnitt festgelegt wird. Dies ist nützlich, um zu testen, wie sich der Wrapper in Situationen von hoher Datenlast verhält, was zur Folge haben könnte, dass mehr Threads des Wrappers wgen Mangel an CPU "verhungern" könnten. Der häufigste Grund für lange Pausen sind hohe EA-Wartezeiten, wenn Tätigkeiten wie Looging getan werden.

  Obligatorischer {THREAD} Parameter:

  Der {THREAD} Parameter wird benötigt für die Werteigenschaft PAUSE_THREADund kann einer der folgenden Werte haben:

  • MAIN :
    

    Der Main-Wrapper-Thread beinhaltet das Überwachen und Pingen des JVM-Prozesses.

  • TIMER :
    

    Der Timer-Thread ist vorhanden, wenn die wrapper.use_system_time Eigenschaft FALSCH ist.

  • JAVAIO :
    

    Der Java-IO-Thread ist vorhanden, wenn die wrapper.javaio.use_thread Eigenschaft WAHR ist.

  • EVENT :
    

    Der Thread, genutzt für alle Event-Aktionen. Nur in der Professional Edition verfügbar.

  Optionaler {TIME} Parameter:

  Der optionale {TIME} Parameter für den Eigenschaftenwert PAUSE_THREAD wird benutzt, um die Anzahl an Sekunden zu spezifizieren, um die der Thread verzögert wird. Gültige Werte sind "-1", oder "0" (Null) bis zu "3600" Sekunden. Ein Wert von "-1" bewirkt eine Pause mit unbestimmter Wartezeit, ein Wert von "0" (Null) hat keinerlei Auswirkung; größere Werte sorgen dagegen für eine Pause um die spezifizierte Anzahl an Sekunden. Der Standardwert ist "-1".

  Während der MAIN-Thread unterbrochen wird, reagiert der Wrapper nicht mehr, so das es notwendig sein kann, das Abbrechen des Wrappers Prozesses zu erzwingen, um zum Zustand vor Ablauf der Pausenzeit zurückzukehren.