Ursprünglich in seiner Historie hat der Wrapper für interne Zeiterfassung stets die Systemzeit genutzt. In der Mehrheit der Fälle funktioniert dies perfekt. Jedoch gibt es ein paar wenige Fälle, in denen dies nicht funktioniert oder der Wrapper sich nicht erwartungsgemäß verhält.:

• Wenn der Wrapper in einer Situation ist, in der mit anderen Prozessen, die mit höherer Priorität ausgeführt werden, um Prozessorleistung konkurriert, ist es möglich, dass der Wrapper und/oder seine JVM über längere Zeitabschnitte keine CPU-Zyklen erhält. Der Wrapper konnte stets mit diesen Fällen durch Einsatz von Logikschaltungen umgehen, die solche Situationen entdecken und alle betroffenen Time-outs entsprechend anpassen. In seltenen Fällen kommt es jedoch vor, dass der Wrapper denkt, dass die JVM eingefroren ist und startet diese dann neu.

• Änderungen der Systemzeit. Wenn die Systemzeit - während der Wrapper läuft - durch mehr als ein paar Sekunden vor- oder zurückgestellt wird, könnten ein oder mehrere Time-outs ausgelöst werden, was einen unbeabsichtigten Neustart der JVM als Folge haben könnte. In den meisten Fällen behandelt der Wrapper Zeitveränderungen, als wenn der Prozess bezüglich CPU-Leistung verhungern würde. Aber es gibt Fälle, in denen dies nicht so funktioniert.

  Im Allgemeinen funktioniert das Voranstellen der Systemuhrzeit korrekt. Eine Nachricht erscheint in der Konsole, die den User darüber informiert, dass der Wrapper seit X Sekunden keine Prozessorleistung erhielt. Aber der Wrapper wird trotzdem weiterhin korrekt funktionieren.

  Das Zurückstellen der Systemzeit kann jedoch eine Zahl von Problemen verursachen - abhängig davon, in welchem Zustand sich der Wrapper befindet, wenn es passiert. Intern setzt der Wrapper Termine für Ereignisse zu spezifischen Zeitpunkten in der Zukunft, wann z.B. Abläufe wie Pingen oder Starten einer neuen JVM stattfinden sollen. Wenn die Zeit um eine Stunde zurückgesetzt wird, dann wird eine Arbeit, die terminiert wurde, nach 5 Sekunden zu erfolgen, für 1 Stunde und 5 Sekunden nicht erfolgen. Wenn das Timing dafür perfekt ist, dann kann es sein, dass der Wrapper aufhört, die JVM zu pingen und die JVM wird auf einen Mangel an Pings mit dem Beginnen eines Neustarts der JVM antworten.

  NOTE

  Sommer-Zeitumstellung

  Der Wrapper funktioniert während Sommer-Zeitumstellung nicht korrekt. Wenn Sie in einem Land leben, welches mag, jeden Frühling und Herbst diese Umstellung zu haben, dann wird empfohlen, dass Sie den "Tick-Timer" benutzen, um Time-outs zu vermeiden.

  Wie oben beschrieben, kann es sein, dass Sie entweder im Frühling oder im Herbst, wenn die Systemzeit angepasst wird, einen einfachen Neustart der JVM bekommen. Sobald die JVM neu gestartet wurde, sollte Ihre Anwendung wieder wie gewöhnlich korrekt funktionieren.

• System unterbricht und fährt fort. Wenn der Wrapper auf einem System genutzt wird, welches auf Festplatte oder RAM für längere zeitdauer unterbrochen werden kann, dann mag es erscheinen, dass die Systemzeit einen Sprung nach vorne gemacht hat, wenn das System die Arbeit wiederaufnimmt. Anders als bei einer Konsolennachricht sollte dies korrekt funktionieren.

Ab der Wrapper-Version 3.1.0, wurde ein neuer Timer-Mechanismus zum Wrapper hinzugefügt. Dieser neuer Timer wurde als Standard in der Wrapper version 3.2.0 fetsgelegt. Statt durch ständige Abfragen der Systemzeit die Zeit aktualisiert zu halten, erstellt der Wrapper einen Hintergrund-Thread, der eine leichtgewichtige schleife anstartet, die den internen "Tick"-Zähler um 1 hochzählt. Intern wurde die komplette Zeiterfassung so geändert, dass diese auf diese "Ticks" basiert. (Wenn die Systemzeit genutzt wird, dann wird das Tick-Zählen zu jedem Zeitpunkt von der Systemzeit statt vom Zähler berechnet.)

Es hat sich herausgestellt, dass dies zahlreiche Vorteile hat:

• Der Wrapper ist dadurch von Änderungen, vorwärts oder rückwärts, an der Systemzeit unabhängig. Dies garantiert, dass der Wrapper sich stets korrekt verhalten wird, wann immer die Systemzeit zwecks Sommer-Zeitumstellung oder für andere Anpassungen angepasst wird.

• Wenn ein unterbrochenes System die Arbeit wieder aufnimmt, wird der Wrapper die Arbeit an der Stelle fortsetzen, bis wo er sie problemlos durchführen konnte.

• Der Wrapper erledigt Fälle, in denen er bezüglich Prozessorleistung Hunger leidet, zuverlässig, weil das Tick-Zählen in einer Geschwindigkeit erhöht wird, welcher der erhaltenen Prozessorleistungsmenge entspricht statt absolut festgelegt zu sein. Das bedeutet, dass Time-outs aufgrund von Hochlastzeiten sehr unwahrscheinllich sind.

  In extremen Fällen, wenn der Wrapper Prozessorleistung erhält, aber die JVM komplett ausgehungert ist, oder andersherum, können Time-outs noch möglich sein. Da die beiden Prozessen jedoch stets mit der genau gleichen Priorität ablaufen, ist dies sehr unwahrscheinlich.

Es gibt jedoch auch ein paar Nachteile bei der Nutzung eines "Tick"-Zählers für die Zeiterfassung:

• Der Tick-Timer erfordert, dass ein zusätzlicher Thread innerhalb des nativen Wrappers zugeteilt wird. Dies führt zu einer geringfügigen Erhöhung des Ressourcenbedarfs für die Ausführung des Wrappers.

  Die Java-Seite des Wrappers macht Gebrauch von einem Thread, der bereits für die Prüfung von Systemsignalen genutzt wurde, so dass es keine Ressourcenerhöhung seitens der Java-Seite gibt.

• Immer wenn sich die CPU-Last unter 100% bewegt, werden die Timer-Threads stets genügend CPU-Leistung bekommen, um ihre Zählerstände hochzuzählen und zeitlich akkurat zu sein. Aber wenn das System unter 100%-Prozessorlast arbeitet , ist der Thread nicht in der Lage, auf voller Geschwindigkeit zu laufen, was bewirkt, dass das Hochzählen langsamer erfolgt. In den meisten Fällen ist dies tatsächlich ein guter Umstand. Jedoch kann es bewirken, dass Abläufe wie z.B. Ping-Intervalle zu manchen Zeiten inkonsistent sein können; dieser Tatsache sollte man sich bewusst sein.

Kompatibel :	3.1.0
Editionen :
Betriebssysteme :

*Die wrapper.timer_slow_threshold Eigenschaft zeigt jedes Mal, wenn der Tick-Timer innerhalb einer einfachen Schleife des Timer-Threads hinter die Systemzeit über einen Schwellenwert an Sekunden zurückfällt, eine Nachricht in der Log-Datei an. Der Standardwert dieser Eigenschaft ist sehr hoch, um sie effektiv zu deaktivieren.*

wrapper.timer_slow_threshold=10

Das Setzen des "langsamen" Schwellenwerts zu einem niedrigen Wert wie 1 Sekunde liefert nützliche Information darüber, zu welcher Tageszeit das System unter Last steht.

Ein Wert von "0" (Null ) zeigt jeden einzelnen Zeitabschnitt an und ist im Allgemeinen nicht sehr nützlich. Sogar unter sehr geringer Last wird der Timer leicht hinter die Systemuhrzeit zurückfallen, einfach aus dem Grunde, weil die Schleife selbst eine endliche Zeitdauer in Anspruch nimmt, um sich zu beenden.

Geringfügig höhere Werte wie 10 Sekunden können normalerweise sehr nützlich sein, da sie die Hauptzeiten von höherer Systemlast anzeigen, während es nicht notwendig ist, jedes kleine Prozessor-Problemchen zu loggen.

Jegliche vorstellende Anpassungen in der Systemuhrzeit werden als eine Zeitdauer von hoher Prozessorauslastung interpretiert, die den Zeitabschnitt dauerten, um den die Uhr vorgestellt wurde.

Wenn Sie z.B. diese Eigenschaft auf einen niedrigen Wert eingestellt haben und die Systemuhr wird entweder um 1 Minute vorgestellt, oder ist unter extrem großer Last für 1 Minute, werden Sie eine Ausgabe in Ihren Logdateien wie folgt sehen:

INFO   | wrapper  | 2004/07/21 08:52:01 | Der Timer fällt hinter die Sytemuhrzeit um 60000ms zurück.
INFO   | jvm 1    | 2004/07/21 08:52:15 |Der Timer fällt hinter die Sytemuhrzeit um 60000ms zurück.

Das Paar an Nachrichten zeigt an, dass beide, der Wrapper und JVM-Prozesse, den Wechsel in der Systemzeit wahrgenommen haben. Es ist gang und gäbe für die Zahlen, die von beiden Berichten gemeldet werden, sich leicht zu unterscheiden, wenn dies durch die hohe Last verursacht wurde.

Kompatibel :	3.1.0
Editionen :
Betriebssysteme :

Die wrapper.timer_fast_threshold Eigenschaft wird die Nachricht in der Logdatei anzeigen, wann immer die Systemzeit hinter den Tick-Timer um mehr als einen Schwellenwert an Sekunden innerhalb einer einzelnen Schleife des Timer-Threads (within a single loop of the timer thread) zurückfällt. Der Standardwert dieser Eigenschaft ist sehr hoch angesetzt, um diese effizient zu deaktivieren.

wrapper.timer_fast_threshold=0

Einstellen des schnellen Schwellenwerts auf einen niederigen Wert Setting the fast threshold to a low value ist im Allgemeinen nicht genauso nützlich wie der langsame Schwellenwert-Eigenschaft oben. Im normalen Betrieb wird der Tick-Timer niemals der Systemzeit vorausgehen. Die einizige Ausnahme ist in dem Fall, wo die Systemzeit zurückgesetzt wurde. Das Festlegen des Eigenschaftswerts auf "0" (Null) ist in der Lage alle Rückwärtsanpassungen der Systemzeit festzustellen.

Wenn Sie z.B. diese Eigenschaft auf einen niedrigen Wert festgelegt haben, und die Systemuhr um eine 1 Minute zurückgesetzt wurde, werden Sie in Ihren Logs Ausgaben :

INFO   | wrapper  | 2004/07/21 08:52:01 | Die Sytemuhrzeit fällt hinter den Timer um 60000ms zurück.
INFO   | jvm 1    | 2004/07/21 08:52:15 | Die Sytemuhrzeit fällt hinter den Timer um 60000ms zurück.

Das Paar Meldungen zeigt an, dass beide, der Wrapper und die JVM-Prozesse die Änderung der Systemzeit festgestellt haben.