backup

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:

@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
}

@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

Hallo Freunde,

letzte Woche Dienstag um 14:08 Uhr hieß es plötzlich „rien ne vas plus“ / „nichts geht mehr“, damit meine ich aber keinen Roulette-Tisch, sondern unsere Hardware-Abteilung. Scheinbar wollten die Kollegen bloß eine Festplatte im Hyper-V tauschen, die der Server aber nicht annehmen wollte, die alte wollte er aber auch nicht haben und die HotSpare-Platte ist nicht eingesprungen (so jedenfalls die Details von den Kollegen – ob das so stimmt?).

Dadurch, dass die Daten also nicht zur Verfügung standen, durften die Kollegen die Wiederherstellung der Daten anwerfen. Bei großen Firmen dauert so etwas in der Regel nicht lange, bei uns hat es insgesamt knapp eine Woche gedauert. Auch wenn es sich hier um einige Virtuelle Festplatten (VHDs) handelt, ist eine Woche definitiv zu viel. Zum Glück waren da nur ein Teil der Server drauf, sodass wir nur einen Teil verlagern mussten.

Ich denke durch so einen GAU sollte man den Leuten gezeigt haben, dass man neue Ressourcen benötigt. Auch wenn diese, zumindest auf den ersten Blick, teuer erscheinen. So sollte unsere Backup-Lösung überarbeitet oder gewechselt werden und der ausgefallene Hyper-V-Server sollte entweder mit in das Cluster der anderen Server mit eingebunden werden (Hardware erforderlich), oder ein eigenes Cluster bekommen (ebenfalls Hardware erforderlich).

Glücklicherweise ging es gestern, urplötzlich, ganz schnell. Erst hieß es noch es könnte bis Ende der Woche dauern, da die Wiederherstellung gerade einmal bei 55% sei. Gegen Nachmittag waren aber bereits die ersten Server online und heute wird der Rest erledigt.

Nunja, hoffentlich passiert das dieser Firma nicht noch einmal, dafür sollte gesorgt werden.

Lukas Kurth Rocks

Java Threads und die Zeit

Ein Woche bei den Nerds ?