Sonderfälle simulieren

Der Aufruf in Abbildung  1 zeigt ein erfolgreich beendetes SQL-Kommando. Viel wichtiger ist es aber, verschiedene vom Normalzustand abweichende Zustände zu provozieren. Mit dem Kommando »select pg_sleep(10)« könnte man beispielsweise einen Timeout in der Query-Funktion erzeugen. Zeile  17 stellt den Timeout auf drei Sekunden ein. Wenn ein SQL-Kommando nun länger als drei Sekunden dauert, wird es mit »$cancel« abgebrochen, und die Query-Funktion gibt die leere Liste zurück. In Zeile  60 wird daraus eine HTTP-Antwort mit dem Code 500 (SERVER ERROR) gemacht.

Der Curl-Aufruf mit dem Parameter »{"action":"test","q":"select pg_sleep(10)"}« müsste also nach drei Sekunden beendet sein und einen Server-Error liefern.

Weiterhin sollte man testen, was passiert, wenn eine ungültige SQL-Anweisung übergeben wird. Dann bricht der Execute-Aufruf in Zeile  47 ab und Curl müsste sofort einen Fehler 500 liefern. Dann könnte man über »/proc/$PID/status« prüfen, ob die Signalmaske des Apache-Prozesses wieder ordentlich zurückgesetzt wurde. Einfacher ist es aber, den Server zu stoppen. Er muss sich wie gewohnt beenden lassen. Wenn die Signalmaske nicht zurückgesetzt ist, würde er eine ganze Weile brauchen und berichten, dass er einigen Prozessen mehrmals ein SIGTERM und schließlich ein SIGKILL geschickt hat.

Wenn ein zeitaufwendiges SQL-Kommando läuft und der Webserver gestoppt wird, sollte das Kommando abgebrochen werden. Das kann man prüfen, indem der Timeout zunächst auf einen großen Wert, zum Beispiel 300  Sekunden, gesetzt wird. Dann startet man das SQL-Kommando »select pg_sleep(50)« und stoppt den Webserver. Auf dem Datenbank-Server muss der zum SELECT zugehörige Prozess verschwinden. Bei geeigneten Logging-Einstellungen taucht im Log der Datenbank folgendes auf:

ERROR:  canceling statement due to user  requestSTATEMENT: select pg_sleep(50)

Nach dem Test des Gerüsts lassen sich weitere Aktionen hinzufügen. Die Chat-Anwendung kommt mit drei Aktionen aus, die ich »enterroom« , »listen« und »sendmsg« getauft habe.

Chat-Ablauf

Abbildung  2 zeigt den zeitlichen Ablauf während eines Chats. Als erstes wird ganz normal die HTML-Seite geladen. Alle weiteren Anfragen werden per XMLHttpRequest in Javascript erzeugt. Daher kann der Request-Body auch sehr einfach in JSON kodiert werden. Betritt der Benutzer einen Chat-Raum, wird »enterroom« aufgerufen. Als Antwort liefert der Server die Liste der Mitteilungen in dem gewählten Raum. Der Browser zeigt diese an und sendet sofort eine »listen« -Anfrage für den Raum. Dieser Aufruf kehrt erst zurück, wenn neue Mitteilungen eingetroffen sind. Will ein Browser eine Nachricht senden, benutzt er die Aktion »sendmsg« . Von der Chat-Anwendung wird daraus ein INSERT-Kommando gemacht. Der Datenbank-Trigger löst aus und schickt eine Notifikation. Die Empfänger lesen die neue Nachricht aus der Datenbank, senden sie an den Browser und beenden damit ihre »listen« -Anfrage. Der Browser zeigt sie an und sendet eine neue »listen« -Anfrage.

Abbildung 2: Die Grundstruktur der realisierten Chat-Anwendung.