Problem mit Longpoll

[Jaydee]

Hallo zusammen!

In einem anderen Thread ( Link ) zeichnete sich vor einiger Zeit ein Problem ab, bei dem FHEM zeitweise - teilweise auch dauerhaft - komplett einfriert. Nach einiger Rumtesterei kommen wir zu dem Schluss, dass es am FHEMWEB bzw. am Longpoll liegen müsste. Nach Deaktivierung von Longpoll in allen FHEMWEB-Instanzen lief FHEM lange Zeit stabil, wenn man es wieder anstellt, kommt es nach kurzer Zeit zum Fehler.

Da Longpoll aber seit einiger Zeit per default aktiviert ist, scheint dieses Problem nicht alle zu betreffen, denn sonst wäre das Geschrei hier im Forum wahrscheinlich groß ;-) Aber bei mindestens 3 Personen tritt der Fehler reproduzierbar auf und lässt sich durch Deaktivierung von Longpoll abschalten.

Da ich die Longpoll-Funktion aber gerne nutzen würde, stellt sich nun die Frage, woran es genau liegt, warum es nicht alle betrifft und wie man das Problem vielleicht auch noch anders lösen könnte.
Es tritt auf jeden Fall auf verschiedenen Systemen auf - ich lasse FHEM auf einem Raspberry Pi laufen, Andyclimb auf einem Core-i3 mit Ubuntu Server 13.04.

Für Anregungen und Tipps wäre ich dankbar.
(Sorry, wenn das jemand als Doppelposting ansieht, aber ich glaube hier - und auf deutsch - ist eine Beteiligung wahrscheinlicher)

[rudolfkoenig]

FHEMWEB schreibt alle events direkt an alle, die es (per inform oder longpoll) bestellt haben. Wenn der (Linux-)Schreibpuffer (48kb?) voll ist, dann wird FHEM blockiert. Das passiert dann, wenn der Abnehmer die Daten nicht abnimmt, oder unerreichbar ist, aber der Linux-Server das noch nicht mitgekriegt hat.

Eine Loesung waere nur dann zu schreiben, falls dieser Schreibpuffer nicht voll ist, was man per select pruefen kann.

Oder man haengt keine Abnehmer an FHEMWEB, die nicht mehr erreichbar sind, das aber auch nicht kundtun.

[Jaydee]

Mit Abnehmer sind jetzt Browser gemeint? Dann ist die Frage, wie sie abnehmen sollen, da auch der Webserver einfriert.

Ich habe häufig auch folgende Anzeige:
(siehe Anhang / see attachement)

..obwohl fhem nur in einem einzigen Tab in einem Browser auf ist.
kann ich dagegen irgendwas tun? Oder gibt es eine Möglichkeit Longpoll nur für die letzte getätigte Anfrage zu aktivieren und ältere abzustellen, sobald es eine neuere gibt?

LG
Jan

[rudolfkoenig]

Der Webserver friert ja nach meine Theorie ein, wenn die Browser nichts abnehmen.

[Jaydee]

Ok, also da ist der Drops dann schon gelutscht...

Aber was ist die Lösung? (außer Longpoll abstellen)
Browsertabs vorm Standby des Computers oder weglegen des Tablets schließen? Meldet sich der Browser damit als Abnehmer ab?
Anderen Browser verwenden als Firefox und Safari?

Warum tritt das Problem dann (scheinbar) nicht bei mehr Leuten auf?
Und woher kommen die parallelen FHEMWEB-Verbindungen (siehe Bild)

[iwan]

Ich habe auch das Problem mit longpoll und hängenden Seiten im Browser.

Wenn der Browser hängt, dann sehe ich über das Telnet-Interface mit dem Kommando
list FHEMWEB.*
ebenfalls 6-8 offenstehende Verbindungen.
Wenn ich diese mit delete FHEMWEB:10.x.x.x:.* lösche, geht die Seite im Browser wieder.

Vielleicht entstehen diese offenen Verbindungen durch JavaScript-Objekte im Browser, die so die Updates von FHEM für die Anzeige im Browser erhalten.

Ich habe diese Effekte sowohl mit Opera-12, Safari (auf iPad) als auch einem alten IE-8

Welche Browser (außer IE) funktionieren bekanntermaßen mit longpoll und den Browser-Skripten ?

Dieses Phänomen habe ich erst nachdem ich von einer alten FHEM-Version aus März 2013 mit
$Id: fhem.pl 2866 2013-03-07 15:10:37Z rudolfkoenig $
auf die aktuelle Version 5.5 gewechselt habe.

[Jaydee]

Also damit scheint es

Firefox 20
Opera 12
Safari (iOS)
IE 8

zu betreffen - quasi die komplette Browser-Bandbreite. Fehlt jetzt eigentlich nur noch Chrome ;-)

EDIT: hmmm, ich habe gerade einmal meinen FHEM-Tab dupliziert und prompt erschienen 5(!) neue FHEMWEB-Instanzen...

[iwan]

Das spricht ggf. für die Vermutung, daß JavaScript-Objekte im Browser die Verbindungen herstellen und blockieren (siehe Rudolfs Vermutung).

[daduke]

Hallo alle,

ich kann den fehlenden Chrome (Linux) beisteuern. Ziemlich frustrierend das ganze, wie Jaydee geschrieben hat: da will man abends alles ausmachen und dann hängt das Interface. Hat schon jemand was Neues zu dem Thema?
Jedes Mal auf Tablet und Smartphone den Browser zu schliessen, bevor diese sich schlafen legen, ist auch nicht ganz realistisch.
@Rudolf: hast Du einen Tip, wo im Source ich anfangen sollte zu graben? Ich bin einigermassen fit in Perl & Co, aber noch ziemlich neu in FHEM.

danke und viele Grüße,
-Christian

[rudolfkoenig]

Sorry, seit dem neuen Forums-Software finde ich solche Anfragen nur zufaellig, da ich nur ueber neue Threads oder welche, wo ich im neuen Forum geantwortet habe, benachrichtigt werde.

Zur Frage: graben brauchst Du nicht, da fehlt noch einiges: Pro Device ein Schreib-Puffer einrichten, und es in der globalen select Schleife schreiben. Und irgendetwas ueberlegen, dass der Puffer nicht beliebig waechst.

Koennt Ihr mir eine einfache Methode nennen, wie ich es nach der Implementierung (werde als naechstes machen) pruefen kann, dass die Massnahme funktioniert?

[herrmannj]

Hallo Rudi,

ja: http://forum.fhem.de/index.php/topic,16001.msg104068.html#msg104068

Habe den Test gerade mehrmals wiederholt, er scheint sicher. Stelle mich als Testkaninchen zur Verfügung

vg
Jörg

[rudolfkoenig]

Habe den write-select implementiert, und es fuer FHEMWEB longpoll/Event-Monitor bzw. telnet inform aktiviert, bitte testen.
Nebeneffekt: wenn der Kernelpuffer voll ist, dann speichert FHEM noch 100kb pro Ausgabekanal.
Achtung: Der Code ist zwar eingecheckt, steht aber erst ab Morgen 7:45 fuer update zur Verfuegung.

Was dabei gelernt: der Linux TCP-Kernelpuffer ist 128kb gross, der von OSX 700kb.
Frueher (war mehr Lametta! war das mal 48kb.
Ein gestoppter telnet unter Linux laeuft weiter, unter OSX bricht es ab.

[Jaydee]

Ok, für die etwas dümmeren unter uns...
Muss ich zum testen irgendwas besonderes tun, oder einfach wieder Longpoll aktivieren und abwarten, was passiert?

[rudolfkoenig]

Duemmere warten bis morgen 8:00, und machen dann ein update.

Longpoll sollte man nicht deaktivieren (per default ist es an).

[herrmannj]

da doppelthreat: http://forum.fhem.de/index.php/topic,16001.msg106282.html#msg106282