dCache Mitarbeit

Meine Aufgabe bestand darin die toString-Methode in der Klasse JobInfo.java in dem Modul dcache-vehicles zu aktualisieren, da diese noch SimpleDateFormat von Java7 verwendete. Dies funktioniert zwar, allerdings ist die Java8 Time API moderner und obendrein threadsafe.  
Die Objekte von JobInfo haben einen SubmitZeitpunkt und einen StartZeitpunkt, welche beide mit demselben SimpleDateFormat-Objekt (Java7) formatiert werden. Allerdings muss man dieses Objekt in einem synchronized-Block aufrufen, da es durch das Parsen  mehrere States durchläuft. Wenn nun mehrere Threads "gleichzeitig" auf SimpleDateFormat zugreifen, bekommen sie es in dem State des vorhergehenden.
Demnach bekommt man dann unterschiedliche Strings zurückgegeben, obwohl alle Threads mit denselben Zeitpunkten für startTime und submitTime (Millisekunden) die toString-Methode aufgerufen haben.

Da es nun eine neue Time API gibt, kann man dieses Problem umgehen, indem man DateTimeFormatter verwendet. Diese Klasse ist threadsafe und man kann auf den synchronized-Block verzichten. Sie arbeitet mit Objekten von Localdate(Time).

Um zu testen, ob die neue Version der toString-Methode auch so funktioniert, dass mehrere Threads sie ohne fehlerhafte returnWerte aufrufen können, habe ich einen Unit-Test geschrieben, der diese Methode in einem Threadpool aufruft.



Hauptsächliche Verbesserungen von NFSv4 zu NFSv2

Das Network File System ermöglicht den Zugriff auf Dateien über ein Netzwerk hinweg als lägen diese auf dem eigenen Dateisystem. Dafür wandelt NFS die Daten mittels der External Data Representation (XPR) in ein plattformunabhängiges Format um und sendet sie als Remote Procedure Calls (RPC) an den Server, an den sich dann der Client zum abrufen wendet.
In einem Entwicklingszeitraum über 11 Jahre und drei Versionen hinweg, verändert sich einiges - von der nicht mehr zeitgemäßen Authentifizierung bis zur Übertragung.
Anstatt den Nutzer mit UserID und GroupID zu identifizieren, wird nun der Username@Domain an den Server übertragen. Dabei ist es im Gegensatz zu früheren Versionen egal, ob auf dem Client eine andere UserID als auf dem Server existiert. Sie müssen nur beide dieselbe Domain haben. 
Zusätzlich läuft die Authentifizierung über Kerberos oder weitere Dienste, welche mithilfe der entsprechenden API kommunizieren. 
Ursprünglich arbeitete NFS zusammen mit dem zustandslosen UDP und IP. Mittlerweile allerdings mit TCP auf einem Port (2049) was sich auch leicht mit Firewalls überwachen lässt. Außerdem lassen sich dank TCP größere read und write Operationen als 8 KB ausführen. 
Um zu vermeiden, dass auf dem Server Daten verloren gehen, ist es nun möglich eine Datei zu locken. Zudem NFSv4 gibt Ressourcen über ein Pseudodateisystem frei, sodass nicht mehr jede freizugebene Datei einzeln gemounted werden muss.