Hallo zusammen!
In einem anderen Thread ( Link (http://forum.fhem.de/index.php?topic=14719.0) ) 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 (//forum.fhem.de/index.php?t=usrinfo&id=884&rid=1021) 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)
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.
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
Der Webserver friert ja nach meine Theorie ein, wenn die Browser nichts abnehmen.
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)
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.
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...
Das spricht ggf. für die Vermutung, daß JavaScript-Objekte im Browser die Verbindungen herstellen und blockieren (siehe Rudolfs Vermutung).
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
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?
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
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.
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?
Duemmere :) warten bis morgen 8:00, und machen dann ein update.
Longpoll sollte man nicht deaktivieren (per default ist es an).
da doppelthreat: http://forum.fhem.de/index.php/topic,16001.msg106282.html#msg106282 (http://forum.fhem.de/index.php/topic,16001.msg106282.html#msg106282)
Also bisher läuft alles mit Longpoll problemlos durch... das kann jetzt natürlich noch zufall sein, aber zuvor kam es schon immer sehr viel schneller zu Problemen. Daher würde ich jetzt einmal vorsichtig von einem Erfolg sprechen.
Vielen Dank!!
Jan
Hallo,
bei mir kommt es auf dem ipad, d.h. Safari iOS 7.03 - und nur mit diesem Browser - immer noch zu dem beobachteten Verhalten. Longpoll ist aktiv. Mein fhem hat alle Updates: # $Id: fhem.pl 4254 2013-11-20 13:04:27Z rudolfkoenig $
Egal ob ich im Safari das FHEM Webfrontend als Tab stehen lasse und später - nach einem App-Wechsel - weiterbedienen möchte oder auch nach Schliessen des Tabs das FHEM Webfrontend neu aufrufe. Es dauert immer ca 60 Sekunden bis sich die Seite aufgebaut hat - dabei hängt der Browser mit "kurzem blauen Balken" oben im Tab.
Während er hängt, sehe ich mit list FHEMWEB.* meistens 6 offene Verbindungen für das ipad. Lösche ich diese während des Hängers geht es sofort weiter.
Kann sonst jemand mit Safari auf dem ios das Verhalten reproduzieren?
Tobias
Edit: Weiter ist noch auffällig, dass das kleine drehende Rädchen auch nach vollendeten Seitenaufbau ständig weiterdreht. Ist das normal?
Ja, das Problem mit dem iPad kenne ich auch zu genüge und ist sehr lästig (wiederholter reload kann helfen). Das ist aber nicht das oben beschriebene Problem, bei dem FHEM komplett still steht, und dann gar nichts mehr geht. Wenn beim iPad nicht vernünftig geladen wird, ist meist von einem anderen Recher aus mit Firefox alles prima - zumindest bei mir.
Lustig ist auch, das wenn das iPad in einem Tab hängt, dann oft ein paralleler Tab mit der lokalen CommandReference mit demselben Fortschitt hängt. Und wenn man dann irgendwann den einen Tab durch abbruch/reload wieder ans laufen bekommt, der andere dann auch weiterlädt.
Ich _meine_ aber dieses Verhalten auf dem iPad auch gehabt zu haben, als ich Longpoll wegen den o.g. Problemen komplett deaktiviert hatte...
Hallo Tobias,
ich hatte auch diese Probleme mit dem IPad und Safari. Mit einem anderen Browser "Dolphin im Fullscreen Modus" hatte ich die Probleme dann nicht mehr.
Gruß,
Ines
Hallo Ines, Jaydee,
danke für eure Tips:
- (mehrfacher) reload im Safari hilft tatsächlich oft
- den Dolphin Browser habe ich ausprobiert - der scheint das Verhalten tatsächlich nicht zu haben. Erstaunlich, weil unter iOS ja eigentlich alle Browser auf dem Apple Webkit zum Rendern basieren (müssen)
- tatsächlich ist der FHEM Server _nicht_ blockiert, wenn der Seitenaufbau auf dem ipad hängt - parallel kann ich z.B. per Firefox oder telnet ohne weiteres zugreifen
- möglicherweise liegt es auch an der Kombination FHEM auf FritzBox und Safari Browser im iOS - ich habe noch eine zweite FHEM-Instanz auf einem QNAP NAS am Laufen bei der ich bisher keine Hänger mit Safari produzieren konnte...
- vielleicht hat es auch wirklich gar nichts mit Longpoll zu tun
Irgendwie scheinen sich die parallel geöffneten FHEMWEB Connects zu verklemmen. Eine Erklärung hierfür könnte wohl Rudolf liefern. Wobei er angeblich ja auch mit iOS und Safari testet...
Wenn es wirklich mehrere betrifft, würde es sich vielleicht auch lohnen einen neuen Thread in der Kategorie Mobile Devices zu eröffnen.
Gruß,
Tobi
Ich hab das problem mit ios safari auch hin und wieder. Wenn ich dann den mac aufklappe und und fhem aufmache renkt es sich meistens wieder ein.