Fallen beim Statuscheck lang laufender PHP-Jobs mit Ajax – IV

Posted on by

Wir setzen mit diesem Beitrag unsere kleine Serie über das Polling von Statusinformationen zu lang laufenden PHP-“RUN”-Jobs auf einem PHP-Web-Server von einem Web-Browser aus fort.

Das “Status-Polling” erfolgt clientseitig mit Hilfe von Ajax-Technologien, über die periodisch CHECKER-Jobs (PHP) auf dem Server gestartet werden, welche spezifische Statusinformationen abfragen, die der RUN-Job während seiner Aktivitäten in einer Datenbank hinterlegt hat. Die Statusinformationen werden per Ajax z.B. als JSON-Objekt zum Browser transferiert und dort in geeigneter Weise angezeigt (z.B. per jQuery-Manipulationen von HTML-Elementen der aktuellen Webseite).

Hierzu hatten wir vorbereitend in folgenden Artikeln einige spezielle Punkte betrachtet. Siehe:
Fallen beim Statuscheck lang laufender PHP-Jobs mit Ajax – I
Fallen beim Statuscheck lang laufender PHP-Jobs mit Ajax – II
Fallen beim Statuscheck lang laufender PHP-Jobs mit Ajax – III

Im ersten Beitrag hatten wir begründet, warum es sinnvoll ist, die Statusinformation in einer Datenbank und nicht in einem PHP-SESSION-Objekt zu hinterlegen. Im zweiten Beitrag dieser Serie hatten wir bereits andiskutiert, dass sowohl der der langlaufende “RUN”-Job als auch die periodisch zu startenden “Checker”-Jobs, die die hinterlegten Statusinformationen zum laufenden “RUN”-Job vom Server “pollen”, von 2 getrennten Formularen ein und derselben Webseite aus über Ajax-Mechanismen gestartet werden. Ferner werden Anzeigebereiche auf der Webseite selbst oder ggf. auch ein per Javascript geöffnetes weiteres Fenster Rückmeldungen und Informationen des RUN-Jobs aufnehmen. Die Statusinformationen werden dagegen in einen definierten Anzeigebereich der Webseite eingesteuert werden.

Zu den Formular – wie auch den Anzeigebereichen der Webseite – definieren wir zur besseren Kapselung unter Javascript “Control-Objekte”, die

  • sowohl die zugeordneten (X)HTML/CSS-Elemente über jQuery-Selektoren, entsprechende Eigenschaften und Methoden,
  • aber auch mehr oder weniger abstrakte innere Verarbeitungsfunktionen für Ajax-Transaktionen und Daten
  • sowie weitere benötigte Datenaufbereitungsfunktionalität

über interne Eigenschaften und Methoden repräsentieren.

Diese Control-Objects kapseln und steuern u.a. die jeweils erforderlichen Ajax-Transaktionen und legen entsprechende Eigenschaften für das XMLHttpRequest-Objekt fest. Wir hatten ferner darauf hingewiesen, dass man bzgl. des Kontextes/Scopes des “this”-Operators bei der Definition der Methoden der Control-Objekete sehr genau aufpassen muss. Bei Einsatz von jQuery hat sich diesbezüglich die Verwendung der $.proxy()-Funktionalität zum Erzwingen des gewünschten Kontextes als sehr hilfreich erwiesen.

Skizzenhafte Übersicht über das Zusammenspiel der Formulare und Jobs

Das Verhältnis zwischen RUN-Job und CHECKER-Job stellt sich wie folgt dar:

Run_Checker

Alle blauen Verbindungen zwischen dem Browser Client und dem Server symbolisieren Ajax-Transaktionen zum Server oder zugehörige Antworten vom Server zum Client.

Ein Formular “FR” übernimmt den Start des RUN-Jobs auf dem Server und übergibt diesem Job Parameter. Zu besagtem Formular gibt es ein Javascript-Control-Objekt “Ctrl_Run“, das die Steuerung des Submit-Prozesss über eine eigene Methode und Ajax-Funktionalitäten von jQuery übernimmt. Dieses Control-Objekt erzeugt außerdem ein neues Browser-Fenster, auf dessen Handler sich danach das Form-Attribut “target” beziehen wird. Entweder wird dieses Attribut bereits in der HTML-Form-Definition definiert oder rechtzeitig vor dem Form-Submit per jQuery gesetzt. Die direkten z.B. per “echo” oder “print/printf” erzeugten Ausgaben des RUN-Jobs erscheinen dann in diesem (Sub-) Fenster des Browsers.

Beim Submit des “FR“-Formulars wird primär der RUN-Job gestartet. Zu beachten ist aber, dass die zugehörige “Ctrl_Run“-Methode über eine spezielle Methode eines weiteren Control-Objekts “Ctrl_Check” zum Formular “FC” auch einen “Timer”-Prozess (Loop) startet, der dann wiederum periodisch den Start eines CHECKER-Jobs auslöst. Hierauf kommen wir gleich zurück.

Man beachte, dass der Start-Button im Formular “FC” mehr symbolisch für einen Submit-Event dieses Formulars steht. Der Submit-Event kann per Javascript natürlich mit einer Methode des Kontroll-Objekts verbunden werden. Dies hatten wir im letzten Beitrag diskutiert.

Der einmal gestartete Run-Job schreibt seinen direkten Output in das dafür vorgesehen Fenster. Der RUN-Job liefert aber auch – eher später als früher – eine hoffentlich positive Ajax-Antwort zurück, für die das Control-Objekt “Ctrl_Run” Verantwortung übernehmen muss. U.a. muss spätestens dann der Timer für das periodische Starten der Checker-Jobs beendet werden. Dies kann durch Aufruf einer entsprechenden Methode des “Ctrl_Check“-Objekts erledigt werden (s.u.) (Natürlich sollte zusätzlich ein Stopp des Timers nach Ablauf eines maximal zugestandenen Zeitintervals vorgesehen werden). Ferner hinterlegt der RUN-Job Informationen zu seinem Zustand in einer dafür vorgesehenen Datenbank-Tabelle (s. den ersten Beitrag der Serie).

Genau diese Status-Informationen werden durch den über Ajax periodisch gestarteten “CHECKER”-Job per SQL abgefragt und z.B. als JSON-Objekt im Rahmen der Ajax-Antwort an den Browser-Client zurück übertragen. Das Control-Objekt für die CHECKER-Jobs stellt die ermittelte Status-Information dann in einem geeigneten HTML-Objekt (z.B. DIV) dar, das ggf. systematisch gescrollt werden muss – soweit es dies nicht selbst bei Füllen mit neuem HTML-Inhalt macht.

Bzgl. der Control-Objects beachten wir die im letzten Beitrag gemachten Ausführungen zum Scope des “this”-Operators.

Die stark vereinfachte Code-Darstellung des letzten Beitrages zeigt, wie die Control-Objekte prinzipiell aufgebaut sein müssen. Das Interessante an unserem Szenario ist, dass wir dabei parallel mit zwei Formularen und (mindestens) 2 entsprechenden Control-Objekten arbeiten. Im Fall des “Ctrl_Check“-Objekts müssen wir nun noch ein periodisches Starten des CHECKER-Jobs auf dem Server gewährleisten.

“this”, setInterval() und das Control-Objekt für das “CHECKER”-Formular

Um den CHECKER-Job periodisch über Ajax anzustoßen, können wir z.B. die Javascript-Funktion “setInterval()” oder innerhalb von Loop-Strukturen auch “setTimeout()” benutzen. Ich betrachte hier nur “setInterval()”. Diese Funktion des globalen “window”-Objektes nimmt als ersten Parameter die Bezeichnung einer (Callback-) Funktion auf, als zweiten Parameter die numerische Angabe eines Zeitintervalls in Millisekunden.

Folgen wir nun unserer früher propagierten Philosophie, dass Methoden eines Control-Objekts “Ctrl_Check” die Steuerung aller (Ajax-) Vorgänge im Zusammenhang
mit dem CHECKER-Prozess übernehmen sollen, so müssen wir

  • einerseits “setInterval(“) durch eine Methode eben dieses Kontrollobjekts aufrufen und
  • andererseits als Callback-Funktion bei der Parametrierung von setInterval() eine per “protoype”-Anweisung definierte Funktion/Methode des Control-Objekts selbst angeben.

Nun könnte man versucht sein, in Anlehnung an die Erkenntnisse des letzten Beitrags Code von ähnlicher Form wie folgender einzusetzen:

Falscher Code:

C_C = new Ctrl_Check_Obj(); 
C_C.startTimer(); 

function Ctrl_Check_Obj() {
	this.interval = 400; 
	this.num_int = 0; 
	this.max_num_int = 200;
 	...
 	this.id_status_form = "# ...."; 
	...
}

Ctrl_Check_Obj.prototype.startTimer = function () {
	this.timex = setInterval(this.submitChecker, this.interval); 
	....
};

Ctrl_Check_Obj.prototype.submitChecker = function(e) {
		
	e.preventDefault();
	....
	// Count nuber of intervals - if larger limit => stop timer 
	this.num_int++;
	if (this.num_int > this.max_num_int ) { 
		this.stopTimer(); 
	}
	....
	....
	// Prepare Ajax transaction 	
	var url = $(this.id_status_form).attr('action'); // in "action" ist der PHP-CHECKER-Job definiert !!!
	var form_data = $(this.id_status_form).serialize(); 
	var return_data_type = 'json'; 
	......
	$.ajaxSetup({
		contentType: "application/x-www-form-urlencoded; charset=ISO-8859-1",
		context:  this, 
		error: this.status_error, 
		.......
	});
	.....
	.....
	// Perform an Ajax transaction	
	$.post(url, form_data, this.status_response, return_data_type); 	
	.......		
	.......  				
};

Ctrl_Check_Obj.prototype.status_response = function(status_result) {
	// Do something with the Ajax (Json) response 
	.....
	this.msg = status_result.msg;
	.....
};

Ctrl_Check_Obj.prototype.stopTimer = function() {
	....	
	clearInterval(this.timex);
};

Das funktioniert so jedoch nicht!

Der Hauptgrund ist der, dass der “this”-Operator der Funktion setInterval() zum Zeitpunkt des Aufrufs der Callback-Funktion auf den Scope des globalen “window”-Objekt verweist – und wieder mal nicht auf den Kontext unseres Control-Objekts. Das ist eigentlich logisch: die Funktion setInterval() muss in Javascript ja völlig unabhängig von bestimmten Objekten realisiert werden. Der einzige konstante Kontext, der sich hierfür anbietet ist der globale. Alles andere erfordert eben entsprechende Zusatzmaßnahmen seitens des Entwicklers.

Der Fehler liegt also in der Definition der setTimer()-Methode – oder besser im der unreflektierten Einsatz von “this”. Wie müssen wir die fehlerhafte Zeile

this.timex = setInterval(this.submitChecker, this.interval);

abändern?

Ein einfacher Ausweg könnte über den globalen Kontext des “window”-Objektes führen. Wir könnten dort globale Funktionen als Callback für setInterval() hinterlegen, die dann wiederum Methoden der definierten Control-Objekte aufrufen. So einfach wollen wir es uns aber nicht machen, denn dadurch würde das Prinzip der Kapselung in Methoden und Variablen unserer Control-Objekten durchbrochen werden.

Der Leser des letzten Beitrags vermutet schon, dass auch hier wieder der “$.proxy()”-Mechanismus von jQuery für eine elegante Lösung zum Einsatz kommen kann. Das ist richtig und sieht dann wie folgt aus:

this.timex = setInterval( $.proxy(this.submitChecker, this), this.interval);

Siehe auch:
http://stackoverflow.com/ questions/ 14608994/ jquery-plugin-scope-with-setinterval

Zu anderen – nicht jQuery-basierten –
Lösungen auf der elementaren Basis von JS-Closures siehe dagegen folgende Artikel:
https://coderwall.com/ p/ 65073w
http://techblog.shaneng.net/ 2005/04/ javascript-setinterval-problem.html

In unserem Fall ergibt sich eine funktionierende Lösung auf der Basis von $.proxy() als : 

C_C = new Ctrl_Check_Obj(); 
C_C.startTimer(); 

function Ctrl_Check_Obj() {
	this.interval = 400; 
	this.num_int = 0; 
	this.max_num_int = 200;
 	...
 	this.id_status_form = "# ...."; 
	...
}

Ctrl_Check_Obj.prototype.startTimer = function () {
	this.timex = setInterval( $.proxy(this.submitChecker, this), this.interval);	
	....
};

Ctrl_Check_Obj.prototype.submitChecker = function(e) {
		
	e.preventDefault();
	....
	// Count nuber of intervals - if larger limit => stop timer 
	this.num_int++;
	if (this.num_int > this.max_num_int ) { 
		this.stopTimer(); 
	}
	....
	....
	// Prepare Ajax transaction 	
	var url = $(this.id_status_form).attr('action'); 
	var form_data = $(this.id_status_form).serialize(); 
	var return_data_type = 'json'; 
	......
	$.ajaxSetup({
		contentType: "application/x-www-form-urlencoded; charset=ISO-8859-1",
		context:  this, 
		error: this.status_error, 
		.......
	});
	.....
	.....
	// Perform an Ajax transaction	
	$.post(url, form_data, this.status_response, return_data_type); 	
	.......		
	.......  				
};

Ctrl_Check_Obj.prototype.status_response = function(status_result) {
	// Do something with the Ajax (Json) response 
	.....
	this.msg = status_result.msg;
	.....
};
Ctrl_Check_Obj.prototype.status_response = function(status_result) {
	// Do something with the Ajax (Json) response 
	.....
	this.msg = status_result.msg;
	.....
};
Ctrl_Check_Obj.prototype.stopTimer = function() {
	....	
	clearInterval(this.timex);
};

Man beachte, dass das “this” im Übergabe-Parameter “this.interval” kein Problem darstellt. Der übergebene Parameter wird beim Setup der globalen Funktion setInterval() direkt im aktuellen Kontext der Ctrl_Check-Klasse ausgelesen und zur Konstruktion des Timer-Loops benutzt. Probleme macht nur der Kontext für die Callback-Funktion, die ohne Eingriffe im Scope des “window”-Objekt von Javascript erwartet werden würde.

Die Wahl eines geeigneten Polling-Zeitintervals

Ein kleiner Aspekt verdient noch etwas Beachtung. Das Schreiben der Statusinformation durch den RUN-Job erfordert Zeit. Das Erscheinen neuer Information hängt von der Art der Aufgaben ab, die der RUN-Job sequentiell erledigt. Ferner erfordert auch der Ajax-Transfer über das Netzwerk/Internet Zeit. Weder eine zu kurze noch zu lange Wahl des Polling-Zeitintervalls – im obigen Code entspricht dies der Variable “interval” der Klasse Ctrl_Check_Obj() – ist daher klug. Wählt man “interval” zu kurz, stauen sich ggf. CHECKER-JObs, ohne dass sie in jedem Lauf überhaupt was Neues an Information liefern könnten. Wählt man “interval” dagegen zu lang, so bügelt man gewissermaßen über die Taktung der Aufgaben und des zugehörigen Status des RUN-Jobs hinweg.

Eine vernünftige Wahl des Polling-Intervalls – also der Periode für das Starten der CHECKER-Jobs – ist daher primär von der zeitlichen Untergliederung, der zeitlichen Granularität des RUN-Jobs abhängig und sekündär von Netzwerk-Transfer-Zeiten, die evtl. in der gleichen Größenordnung liegen mögen. In vielen meiner Fälle ist 500 msec ein guter Startwert.

Zusammenfassung

Aus meiner Sicht habe ich hiermit die grundsätzlichen Werkzeuge beleuchtet, die auf der Javascript-Seite – also der Client-Seite für das “RUN/CHECKER”-Szenario zum Einsatz kommen sollten.

Die PHP-Seite ist eher langweilig und erschöpft sich in elementaren Datenbanktransaktionen sowie einem Standard-JSON-Encoding der gesammelten Informationen für den Ajax-Transfer. Das sind aus meiner Sicht elementare Ajax-Dinge, die hier nicht weiter beleuchtet werden müssen. Hingewiesen sei auf den möglichen Einsatz der PHP-Funktion 

json_encode($ay_ajax_response);

zur Codierung der Resultate, die etwa in einem assoziativen Array “json_encode($ay_ajax_response)” gesammelt wurden.

Welche Informationen als Statusinformationen in der Datenbank hinterlegt, dann vom CHECKER-Job gelesen und zum Web-Client transportiert sowie schließlich im Web-Browser optisch aufbereitet und angezeigt werden, ist natürlich vom Einsatzzweck des RUN-Jobs abhängig.

Somit beenden wir nun unseren Ausflug bzgl. potentieller Fallen, in die man beim Setup eines RUN/CHECKER-Systems zum Pollen von Statusinformation von einem Web-Client aus über den Zustand eines lang laufenden Server-Jobs stolpern kann. Wir fassen abschließend einige wesentliche Punkte der Beitragsreihe zusammen:

  1. Der lang laufende PHP Server-Job “RUN” sollte seine zwischenzeitlichen Statusinformationen in eine Datenbank-Tabelle und nicht in ein SESSION-Objekt schreiben.
  2. Das Starten und die Ajax-Transaktionen für den RUN-Job und die CHECKER-Jobs können über zwei Formulare einer Webseite und parallel abgewickelt werden. Die Kontrolle der Transaktionen übernehmen “Control-Objekte“, die über Methoden (prototype-Funktionen) die Ajax-Umgebung und die Callbacks für die Response/Error-Behandlung definieren.
  3. Bei der Kapselung der Ajax-Response/Error-Behandlung in Methoden der Control-Objects ist der Scope/Kontext für den “this”-Operator zu beachten. Der Einsatz der $.proxy()-Funktionalität von jQuery hilft hier, schnell, elegant und ohne explizite Ausformulierung von Closures zum Ziel zu kommen.
  4. Auch beim der Steuerung des periodischen Starten der CHECKER-Jobs mittels Methoden eines geeigneten Control-Objects und setInterval() hilft $.proxy() bei der Kapselung der periodischen Ajax-Transaktionen bzgl. CHECKER im Kontext des zuständigen Control-Objects.
  5. Das Zeitintervall für das periodische Starten der CHECKER-Jobs muss an die zeitliche Granularität der Aufgabnebehandlung im RUN-Job und an evtl. Netzwerk-Latenzen angepasst werden.

Viel Spaß nun mit der Überwachung des Status von lang laufenden PHP-Jobs von einem Web-Client aus.

Hingewiesen sei abschließend darauf, dass die gesamte Methodik natürlich auch viel allgemeinerer Weise dazu benutzt werden kann, um mehrere Jobs eines Web-Servers von einem Web-Client aus zu starten und zu überwachen. Dies ist auch deswegen interessant, weil ein evtl. gewünschtes Threading von PHP-Jobs spezielle Maßnahmen auf dem Server erfordern. Manchmal ist es viel einfacher Ajax auf dem Client einzusetzen, um mehrere Jobs auf dem Server zu starten und zu kontrollieren. Ein ggf. erforderlicher Informationsaustausch zwischen den laufenden Jobs lässt sich dabei in vielen über die Datenbank erledigen.