Guten Morgen meine IT-Kollegen,
gerade stieß ich wieder auf ein Problem, welches unter normalen Umständen nicht auftreten sollte: Die Uhrzeit des Hosts ändert sich. Dies sollte bei Programmen die keine Threads haben, oder Threads, die alle paar Stunden einmal ausgeführt werden sollen, in der Regel kein Problem sein. Bei Threads die wichtige Daten alle paar Minuten auswerten / verschieben / löschen sollen, kann dies aber unter Umständen zu dem Problem führen, dass der Thread erst bei der nächsten Uhrzeit ausgeführt wird (Thread.sleep(), Timer und der TimerTask sind hier so Kandidaten).
Zur Veranschaulichung folgende Situation die ich letztens hatte: Ein Programm verschiebt Daten alle X Sekunden (oder sobald eine Datei in ein C:\Pfad landet) auf einen UNC-Pfad. Jetzt wird die nächste Ausführung durch den Timer auf die aktuelle Zeit plus den eingestellten Delay gesetzt. Auf Grund eines Backup-Systems mit einer falschen Uhrzeit, wird die Zeit des Hosts mit der Zeit des Backup-Systems, ein eigenes System mit leider falsch eingestellter Uhrzeit welches von meinem Kollegen verwaltet wird, synchronisiert (sollte nicht passieren, aber das ist ein anderes Thema) und somit um 2 Stunden nachgestellt.
Der Thread wird wieder ausgeführt und setzt die Zeit wieder auf die veränderte aktuelle Zeit plus den vorher eingestellten Delay. Das Backup System wird anschließend fertig und die Zeit wird wieder auf die vorherige zurück gestellt. Jetzt hätten wir auf dem Host beispielsweise 10:00 Uhr, auf dem Backup-System 12:00 Uhr und der nächste Thread würde um 12:02 Uhr anfangen. In den zwei Stunden macht das Programm gar nichts, da der Thread geplant ist und so gesehen kein Fehler zum Auswerfen vorliegt.
So weit dazu.
Dies scheint vor allem an den von Java verwendeten Funktionen zu liegen. Allen voran die Funktion System.currentTimeMillis(). Man könnte nun eigene Klassen und Funktionen schreiben, die statt dieser die Funktion System.nanoTime() verwendet, aber dann müsste man die damit zusammenhängenden Funktionen auch neu schreiben und da diese leider meist private deklariert wurden die entsprechenden Klassen gleich mit dazu.
Sowas mache ich meist eher ungern 😉
Eine gute Möglichkeit für den Ersatz von java.util.Timer (oder entsprechender anderer Klasse) ist ein ScheduledThreadPoolExecutor. Dies könnte in Verwendung in etwa wie folgt aussehen:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@Override public void start() { ScheduledThreadPoolExecutor scheduler = new ScheduledThreadPoolExecutor(1); ArrayList<TimerTask> tasks = new ArrayList<>(); tasks.add(new NetworkInterfaceTask(tools)); tasks.add(new InternetConnectionTask(tools)); tasks.add(new ClockTask(tools, masterTimestamp)); tasks.add(getReachableTask()); scheduler.scheduleAtFixedRate(tasks.get(0), 5, 5, TimeUnit.MINUTES); // NETWORK scheduler.scheduleAtFixedRate(tasks.get(1), 5, 5, TimeUnit.MINUTES); // INTERNET scheduler.scheduleAtFixedRate(tasks.get(2), 2, 2, TimeUnit.SECONDS); // CLOCK scheduler.scheduleAtFixedRate(tasks.get(3), 5, 5, TimeUnit.MINUTES); // REACH } |
Ist natürlich nur ein Beispiel. Man könnte unter anderem die return Werte von scheduleAtFixedRate() in einem Future Array speichern und dann abfragen, aber das gehört in einen anderen Beitrag 😉
Viel Spaß beim Programmieren
Lukas
