In den letzten Wochen habe ich intensiv an meinem Raspberry Pi-Dashboard für unser Apartment geschraubt und gebastelt. Verschiedene Tiles werden mittels AJAX-Requests, welche über jQuery abgesetzt werden, mit Inhalten versorgt — und dies regelmässig alle paar Minuten.
Ein mysteriöser Bug machte mir in den letzten Tagen das Leben schwer: Es konnte vorkommen, dass zwei Tiles mit den Aktienkursen desselben Unternehmens gefüllt wurden, obwohl die Tile-IDs unterschiedliche ISINs trug.
Nach einigen Minuten Debugging schwante mir dann plötzlich, was das Problem war: Der auf dem Server lokal zwischengespeicherte HTML-Cache war zwar in Dateien mit der richtigen ISIN im Dateinamen abgelegt — der Inhalt war aber identisch. Konkret enthielt die HTML-Datei über das Unternehmen AAPL die Daten für das Unternehmen GOOG.
Wie sich heraustellte, hatte ich mein Script nicht dermassen intelligent programmiert, dass es mit mehreren, nur wenige Millisekunden auseinanderliegenden Requests ordnungsgemäss umging. Um nämlich den Aktienkurs einer ISIN abzufragen, muss dieser zuerst über einen HTTP-Request an ein Suchscript meines unfreiwilligen Kursanbieters in eine vom Anbieter intern verwendete NOTATION_ID umgewandelt werden (was wissbegierigen Lesern dieses Blogs einen Hinweis gibt, von welcher Web-Site ich die Kursdaten beziehe). Erst danach kann ich die Informationsseite des auf dem Aktienmarkt gehandelten Unternehmens aufrufen, herunterladen und im lokalen Dateisystem ablegen.
Konkret war mein Fehler, dass ich die Suchergebnisse zur Umwandlung der ISIN in die NOTATION_ID in eine Cache-Datei mit statischem Dateinamen ablegte. Da die Requests mit wenigen Millisekunden Versatz beim Server ankamen, war die Cache-Datei manchmal bereits von einem späteren Request überschrieben worden, als ich den HTML-Code endlich in PHP einlesen wollte (ich denke, dass wir hier von einigen wenigen hundert Millisekunden sprechen). Dies führte dazu, dass ich einer ISIN fälschlicherweise die NOTATION_ID des nachfolgenden Requests zuwies und diese plötzlich für zwei Kursanbieter galt. Da ich dieses Mapping aus Performance-Gründen ebenfalls serialisiert in einer Cache-Datei ablegte, wurden ab diesem Zeitpunkt zwei Tiles mit identischen Inhalten befüllt.
Die erste Lösung, dem Dateinamen einen sich ständig ändernden Wert einzupflegen, scheiterte grandios, weil ich time() verwendete. Da die Requests innerhalb der selben Sekunde auf dem Server eintreffen konnten, konnte die Cache-Datei im schlimmsten Fall weiterhin vom nachfolgenden Request überschrieben werden. Die zweite Lösung war deshalb, durch das Einfügen einer mittels rand(1000,9999) definierten Zufallszahl einen wahrlich zufälligen Wert in den Dateinamen einzuschleusen. Die Chancen, einen identischen Cache-Namen zu erwischen, ist hier 1:10000 — good enough, würde ich sagen.
Natürlich hätte ich auch einfach die ISIN in den Namen der Cache-Datei aufnehmen können. Hier hegte ich aber Zweifel, weil ich nicht wollte, dass bei einem Downloadfehler einfach unbemerkt die bestehenden, veralteten Daten eingelesen würden.
