World Map
Java Service Wrapper ist der einfachste Weg, um Ihr Produkt zuverlässiger, sicherer zu machen.
  • Free Trial
  • Buy Now
wrapper.commandfile Eigenschaft

wrapper.commandfile

Kompatibel :3.2.0
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

WARNING

Ändern Sie nicht irgendwelche dieser Parameter, solange Sie nicht die Beschreibung der Eigenschaft gelesen. Inkorrekte Einstellungen können dafür sorgen, dass der Wrapper nicht so wie erwartet funktioniert.

Datei, die bezüglich den auszuführenden Befehlen überwacht wird. Diese Eigenschaft ist standardmäßig nicht bestimmt.

Diese Eigenschaft ist für die meisten Anwendungen irrelevant, aber sie kann für externe Anwendungen nützlich sein, die den Wrapper auf eine plattformübergreifende Weise überwachen müssen.

Wenn diese Eigenschaft gesetzt ist, wird der Wrapper in regelmäßigen Zeitintervallen nach der Existenz einer bestimmten Datei überprüfen. Falls gefunden, wird die Datei geöffnet und alle Befehle werden in Reihenfolge ausgeführt. Die Datei wird bei vollständiger Ausführung der Befehle gelöscht werden.

Beispiel:
wrapper.commandfile=./myapp.command

NOTE

Sicherheitsrisiko:

Seien sie sich bitte bewusst, dass die Nutzung dieser Eigenschaft ein Sicherheitsrisiko darstellen kann, da der Wrapper einfach durch Erstellen einer Textdatei kontrolliert werden kann. Aus diesem Grund stellen Sie bitte sicher, dass die Berechtigungen auf dem Verzeichnis, welches die Befehlsdatei enthält, entsprechend richtig gesetzt sind.

Nutzen der Befehlsdatei

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.

wrapper.commandfile.enable_tests

Kompatibel :3.5.0
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

Einige der Befehle, die für das Testen relevant sind, sind aus Sicherheitsgründen standardmäßig deaktiviert. Diese Eigenschaft auf WAHR einzustellen, macht es möglich, Testbefehle zu nutzen. Der Standardwert ist "FALSCH".

Beispiel:
wrapper.commandfile.enable_tests=FALSE

Die folgenden Testbefehle können gültig sein:

  • PAUSE_LOGGER {seconds} (Since version 3.5.11) :

    Bewirkt, dass der Wrapper in der nächsten Zeile der Logausgabe für die Zahl an Sekunden pausiert. Sehen Sie die vollständige Beschreibung oben.

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

    Bewirkt, dass der spezifizierte Wrapper-Thread mit dem folgenden Parameter für eine bestimmte Zeitdauer pausiert wird. Sehen Sie die vollständige Beschreibung oben.

  • CLOSE_SOCKET (Since version 3.5.0) :

    Bewirkt, dass das Back-End Socket mit der JVM sofort geschlossen wird. Sehen Sie die vollständige Beschreibung oben.

NOTE

Bitte beachten Sie, dass einige Testbefehle bewirken können, dass der Wrapper oder die JVM instabil wird. Diese sind nur zum Testen bestimmt und sollten niemals auf produktiven Servern aktiviert werden.

wrapper.commandfile.poll_interval

Kompatibel :3.2.0
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

Das übliche Zeitintervall, zu dem auf Existenz der Befehlszeile überprüft wird, kann durch Nutzen dieser Eigenschaft gesteuert werden. Der Standardwert ist 5 Sekunden, mit gültigen Werten im Bereich von "1" zu "3600" Sekunden".

Beispiel:
wrapper.commandfile.poll_interval=5

Verweis: Befehlsdatei