Seit der DDOS haben einige Loseseiten wohl Probleme mit fehlenden Rückantworten von EF. Wir haben jedoch nichts umgestellt, außer den Keepalive der LoadBalancer OFF zu stellen (vorher 10sek). Dadurch kommt der Connection:close-Header an einer anderen Stelle innerhalb der HTTP-Header der EF-Antwort, was aber im Prinzip egal sein sollte.
Einige Losescripte werten diese Header wohl in einer Art und Weise aus, sodass das als "keine Antwort" interpretiert wird (obwohl die HTML-Antwort ganz normal mitgesendet wird). Ergebnis davon sind dann Einzahlungen auf Loseseiten ohne interne Verbuchungen auf die Userkonten etc.
Bisher konnte (oder wollte) mir niemand Einsicht in ein solches Problemscript geben oder mich auf eine Maschine lassen, auf der das Ganze reproduzierbar auftritt. Eine Fehlermeldung (keine Ahnung welches Lose-Script die produziert) lautet wohl ...
Solltet ihr von EF/Scripten eine "Connection:close"-Meldung erhalten - meldet Euch bitte oder schaut selbst mal, wo genau das Problem mit der EF-Kommunikation liegt. Hilfreich wären auch komplette(!) Header einer solch problematischen EF-Antwort und ob es *immer* auftritt oder nur ab und zu. Es gilt zu klären, ob es an den Lose-Scripten, an der lokalen Serverkonfiguration der Loseseiten oder an der Serverkonfiguration von klamm.de liegt.
Notlösung
In den Losescripten www.klamm.de durch wwwX(1-6).klamm.de ersetzen. Dann tritt der Fehler nicht mehr auf - aber ACHTUNG: Ihr seid dann auch nicht mehr im Cluster eingebunden und damit nicht mehr überlastungs- und ausfallsicher. Es sollte also nur eine temporäre Notlösung sein, bis das Problem gefunden und behoben ist.
EF-Confirm
Mit der EF-Confirm-API lassen sich fehlende Transaktionsergebnisse im Nachhinein abrufen (also genau für solche Probleme anwendbar). Gute Lose-Scripte sollten dies unterstützen.
Code:
[COLOR=#000000][FONT=arial]HTTP-Response mit KeepAlive:
--
HTTP/1.1 400 Bad Request
Date: Thu, 18 Dec 2008 09:46:16 GMT
Server: Apache
Connection: close <----
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
[html]
--
ohne KeepAlive:
--
HTTP/1.1 400 Bad Request
Date: Thu, 18 Dec 2008 09:45:50 GMT
Server: Apache
Content-Length: 289
Content-Type: text/html; charset=iso-8859-1
Connection: close <----------------------------
[html]
--[/FONT][/COLOR]
Bisher konnte (oder wollte) mir niemand Einsicht in ein solches Problemscript geben oder mich auf eine Maschine lassen, auf der das Ganze reproduzierbar auftritt. Eine Fehlermeldung (keine Ahnung welches Lose-Script die produziert) lautet wohl ...
Aufruf an alle Lose-Scripte-Coderfolgender Fehler ist aufgetreten:
Connection: close
1001: Klamm nicht erreichbar!
Solltet ihr von EF/Scripten eine "Connection:close"-Meldung erhalten - meldet Euch bitte oder schaut selbst mal, wo genau das Problem mit der EF-Kommunikation liegt. Hilfreich wären auch komplette(!) Header einer solch problematischen EF-Antwort und ob es *immer* auftritt oder nur ab und zu. Es gilt zu klären, ob es an den Lose-Scripten, an der lokalen Serverkonfiguration der Loseseiten oder an der Serverkonfiguration von klamm.de liegt.
Notlösung
In den Losescripten www.klamm.de durch wwwX(1-6).klamm.de ersetzen. Dann tritt der Fehler nicht mehr auf - aber ACHTUNG: Ihr seid dann auch nicht mehr im Cluster eingebunden und damit nicht mehr überlastungs- und ausfallsicher. Es sollte also nur eine temporäre Notlösung sein, bis das Problem gefunden und behoben ist.
EF-Confirm
Mit der EF-Confirm-API lassen sich fehlende Transaktionsergebnisse im Nachhinein abrufen (also genau für solche Probleme anwendbar). Gute Lose-Scripte sollten dies unterstützen.