Unser Hosting Control Panel unterstützt ja auch MySQL als Backend zur Speicherung der “eigenen” Daten. Der Zugriff auf MySQL erfolgt aus Performancegründen ausschließlich mittels Prepared Statements. Nun hat uns kürzlich ein LiveConfig-Kunde auf ein merkwürdiges Problem aufmerksam gemacht: regelmäßig erschien nach der Durchführung eines MySQL-Backups (via mysqldump) in LiveConfig die Fehlermeldung “Prepared statement needs to be re-prepared”.

Die Suche hiernach führte zum MySQL-Bug #41119. Als Workaround haben wir daher nun eine explizite Fehlerbehandlung nach mysql_stmt_execute() eingeführt, welche mit mysql_stmt_errno() die jeweilige Fehlernummer ausliest und in unserem Fall (Fehlercode 1615) das betroffene Statement explizit neu erzeugt.

Nur leider funktionierte dieser Workaround nicht. Also überhaupt nicht.

Ein ausführliches Debugging und Tracing aller Datenbankzugriffe hat dann ergeben, dass unsere Fehlerbehandlung gar nicht aufgerufen wird. Zusätzliche Debug-Ausgaben bestätigten dann tatsächlich, dass mysql_stmt_errno() immer “0″ zurückliefert! WTF!?!?

Diesmal hat MySQL-Bug #53311 zugeschlagen. Beseitigt ist dieser Fehler seit knapp einem Jahr ab MySQL Connector/C 6.0.3. Dummerweise ist diese Version aber nach wie vor nicht freigegeben (”aktuell” verfügbar ist nur Version 6.0.2).

Letztendlich haben wir hier nun den über 650 MB großen bazaar-Branch von libmysql ausgeckeckt, und müssen uns nun zwangsweise die 6.0.3-Release selbst erzeugen…

Nachtrag:

Finger weg vom MySQL-Connector/C 6.0.3! Ich glaube zu verstehen, warum diese Version noch nicht freigegeben wurde - da funktioniert die Hälfte nicht mehr… vor allem bei Prepared Statements scheint diese Version besonders merkwürdige Fehler zu haben - so funktioniert selbst ein einfaches UPDATE mit drei bestimmten Parametern (String/Int/String) reproduzierbar nicht mehr; ändert man die Reihenfolge der Parameter (zB. String/String/Int oder Int/String/String) so klappt’s plötzlich wieder. Und der Bug liegt definitiv nicht bei uns - selbst ein eigenes Testprogramm (basierend auf dem Beispiel von MySQL) führt bei einer bestimmten Variablenfolge zu einem “Incorrect arguments to mysqld_stmt_execute”. Ob das mit MySQL-Bug #61225 zu tun hat weiß ich nicht, aber auch dessen Fehlerbeschreibung lässt einen fast erschaudern.

Der Trick zu einem stabilen und aktuellen MySQL-Client führt über die GA-Pakete des Community-Servers. Einfach dort die entsprechenden Bibliotheken und Developer-Pakete zusammensuchen, oder aus dem “Generic”-Paket (.tar.gz) die Verzeichnisse “/lib” und “/include” nehmen. Der Client aus MySQL 5.5.20 spricht ebenfalls Protokollversion 10 (wie auch Client 6.0.x), dürfte daher soweit kompatibel sein. Man muss seinen eigenen Code allerdings neu gegen diese Bibliotheken linken, da es ein paar kleinere ABI-Unterschiede gibt.

Leider (noch) nicht - es handelt sich “nur” um einen Vertrag zur Auftragsdatenverarbeitung für Google Analytics…

So fängt LiveConfig in der nächsten Version (1.3) auch solche falschen Zugriffe ab und bietet dem Benutzer die “richtige” URL an. Ein kleines, aber praktisches Feature.

Eventuell werden wir bei Gelegenheit auch einen Test einbauen, ob bei HTTP-Verbindungen ein SSL-Handshake eintrifft, um dann ebenfalls eine entsprechende Fehlermeldung zu erzeugen.

Gleichzeitig sollte in überwiegend weiblich besetzten Berufen eine Männerquote gesetzlich vorgeschrieben werden. Grundschulen mit weniger als 30% männlicher Lehrer gehören umgehend durch allseits beliebte Finanzstrafen sanktioniert.

Und nicht zuletzt sollte endlich gesetzlich geregelt werden, dass es an Weihnachten immer zu schneien hat!

Gut, dass es offenbar derzeit keine anderen Probleme gibt.

Und per Zufall bin ich eben über die Beschreibung eines mit Kartoffeln betriebenen Webservers gestoßen. Wäre doch auch mal eine Idee.

Gepflegt wurde tz-data bisher von Arthur Olson und Paul Eggert - und zwar völlig unentgeltlich. Gestern wurde die Site geschlossen.

Hintergrund ist die Klage eines Verlags, der ein Buch über Zeitzonen in Amerika (bis 1991) und ein dazugehöriges Computerprogramm herausgebracht hat. Die in dem Buch veröffentlichten Informationen sind zumindest teilweise auch in tz-data enthalten, und das mißfällt diesem Verlag. Ob die Informationen über Zeitzonen tatsächlich urheberrechtlich geschützt werden können ist recht umstritten - einerseits können keine Rechte auf Fakten beansprucht werden (und darum handelt es sich bei Zeitzonen), andererseits können Inhalte von Datenbanken unter bestimmten Voraussetzungen durchaus geschützt werden.

Jedenfalls hat sich der Verlag mit dieser Klage selbst ins Knie geschossen: in tz-data wird deren Buch als Informationsquelle empfohlen - was sich künftig ändern dürfte.

Die Folgen sind derzeit noch nicht absehbar. Bestenfalls wird die Klage abgewiesen oder abgeschmettert, und die Pflege der Datenbank fortgesetzt. Schlimmstenfalls findet nun eine “Fragmentierung” der Zeitzonen-Datenbanken statt; schließlich muss jeder Unix-/Linux-Hersteller nun selber die Zeitzonen-Änderungen einpflegen. Eine neue Mailingliste hierfür wurde bereits eingerichtet.

Außerdem gibt es Bestrebungen, die Verwaltung der tz-Daten in die Hand der IANA zu übergeben. Interessanterweise stammt der IETF-Draft vom 19.05.2011, nachdem Astrolabe wohl schon am 12.05.2011 die Schließung der tz-Website verlangt hat (siehe Klageschrift).

Ich hoffe mal, dass da schnell eine Lösung gefunden wird. Vor allem gehe ich davon aus, dass die “Großen” (RedHat, SuSE (Novell), Oracle, …), welche tz-data in ihren Distributionen nutzen, für die notwendige Unterstützung sorgen.

Die Technik ist beeindruckend (insbes. die KI bei der Spracherkennung), und die Hardware atemberaubend. Trotzdem brauche ich nach wie vor kein iPhone.

Es ist unglaublich beruhigend, unterwegs mal keine E-Mails lesen zu können.

[NACHTRAG] Was mich wirklich schockiert ist die Tatsache, dass Apple die Idee eines Tablet-PC mit Sprachsteuerung bereits 1987 fast exakt vorausdatiert hat - auf den 16. September 2011.

Angekommen sind die Pakete aber mit einem “normalen” Lieferwagen.

This is what matters: launching products, getting them in the hands of users, and hearing them get value out of it. That’s why we stay up late, ruin our wrists and our eyesight, and drive our families crazy. It’s all about shipping.

Und wie es der Zufall so will: soeben wurde LiveConfig 1.2.0 - die erste “produktive” Version - online gestellt.

Für Blog-Beiträge werde ich in den nächsten zwei Wochen vermutlich kaum Zeit haben, da nun ein äußerst straffer Zeitplan abläuft. Das nächste Release (1.2.1) ist bereits in Arbeit. Nun wird’s ernst - der Kreis produktiver Nutzer wächst nun stetig an. Und es gibt auch nach wie vor eine Menge an fehlenden oder optimierbaren Funktionen - aber irgendwann muss man schließlich mal eine erste “echte” Version freigeben. It’s all about shipping.