Wenn ihr denkt, dass GPSies keine Arbeit mehr erzeugt, dann irrt ihr. Aber ich glaube, das denkt keiner ;-), da bin ich mir fast sicher. Die letzten Wochen habe ich intensiv an Optimierungen, der Integration des neuen Servers, der neuen API (bisher nur für die neue iPhone App) und an einem Phänomen gearbeitet, welches mir (und vielleicht auch euch) seit längerer Zeit ein paar “Schmerzen” bzw. ziemlich “pain in the ass” bereitet hat.
Der Artikel ist sehr technisch, also nichts für Weicheier :-)
Bei GPSies werden ja alle Downloads dynamisch zur Laufzeit erzeugt. Das geht ja auch nicht anders, denn wer will schon für fast 800.000 Strecken nahezu 25 GPS Formate vorhalten. Das kann ich ja schon fast gar nicht mehr im Kopf ausrechnen – ich habe es aber trotzdem mal gemacht: 20.000.000 Dateien. Täglich kämen 50.000 neue Dateien hinzu (ca. 2.000 Strecken mal 25 GPS Formate).
Nun sind ja auf GPSies einige Leute gleichzeitig unterwegs. Die Zahl wird unten angezeigt, in der Regel sind das meist über 1.000 Benutzer-Sessions. Gut, nicht jeder konvertiert, lädt hoch oder runter zur gleichen Zeit, aber es kommt schon mal vor, dass mal 20 Dateioperationen gleichzeitig laufen.
GPSies wurde ja komplett in Java entwickelt. Zur Konvertierung der GPS Dateien benutze ich nicht, wie vielleicht viele andere Portale GPSBabel, sondern benutze eine komplett eigene Implementierung. Das ist auch gut so, denn wenn vielleicht mal bei GPSBabel eine Datei nicht konvertierbar ist, dann geht das vielleicht bei GPSies.
An einigen Tagen hat das Konvertieren von GPX und TXC Dateien nicht richtig funktioniert. Besonders an heißen Tagen, wenn besonders viel los war, z.B. an Ostern. Die Dateien wurden zwar ausgeliefert und waren valide, aber ausgerechnet das Garmin TCX (und auch GPX) Format hat beim Einlesen versagt – die Dateien konnten nicht auf den Garmin übertragen werden. Warum? Weil in diese Dateien immer ein aktueller Timestamp (“Zeitstempel”) eingewebt werden muss, was aber in ein paar wenigen Fällen nicht funktionierte (dient u.a. dazu, dass dem virtuelle Partner eine Geschwindigkeit vorgegeben wird). Die Zeitangaben in den Dateien war schlichtweg falsch, der Zeitstrahl hatte falsche Timestamps drinnen.
Jetzt wird es noch spezieller, “Nichtteckies” bitte jetzt abbrechen.
Zur Berechnung der Zeit bzw. zur richtigen Formatierung des Datumsfeldes in der XML Datei benutzte ich seit Jahren die Klasse java.text.SimpleDateFormat. Bei hoher Belastung bekam ich immer den Fehler bzw. die Exception:
java.lang.ArrayIndexOutOfBoundsException: 432
at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:436)
…
Das Problem ist anscheinend bekannt und die Entwickler von Java schreiben, dass die Klasse Methode nicht “thread-safe” designed wurde. Gut, das ist ja auch ok und sogar in der Spezifikation beschrieben. Doch wer liest die schon so genau ;-)? Die Java-Cracks unter den Lesern werden jetzt gähnen und sagen: “Det is doch klar, det wees doch jeder”. Aber so klar ist das nicht, wie man auf einschlägigen Seiten lesen kann.
Eine Umschiffung des Problems hätte die Benutzung von “synchronize” bedeutet. Aber synchronisierte Operationen bei einem so beanspruchten System wie GPSies hätte nicht funktioniert, das hätte massenhaft Verzögerungen und Fehler gegeben. Und jedes Mal eine neue Instanz des SimpleDateFormat zu erzeugen, hätte wohl den Speicher der Applikation aufgefressen.
Was nun?
Tata: it’s Joda Time!
Joda Time ist ein auf Sourceforge gehostetes Projekt, das die Benutzung von SimpleDateFormat dank des DateTimeFormatters umschifft.
Ob Meister Joda tatsächlich beim Namen des Projektes Pate stand, weiß ich nicht. Aber so ein technischer Artikel braucht halt ein paar Bilder…
Jedenfalls ist die Änderung seit Anfang der Woche online und ich habe seit dem keine ArrayIndexOutOfBoundsException mehr gesehen.
Ende gut, alles gut, jetzt geht’s!