longpoll + ausgeschalteter client + vieeele status updates = fhem hängt.

[Andre]

Hallo,

ich habe heute das gleich Problem gehabt, das Update behebt das Problem. Danke dafür. Immer wenn ich eine Seite aufrufen wollte, hing der Browser, wenn ich dann Stop (im Browser) geklickt habe, war die Seite da. Quasi nicht bedienbar.

Ich habe folgende Konfiguration (nahezu alle kreuz und quer getestet):

- rPi (512MB) mit wheezy
- ClientOS: iOS, Windows, Ubuntu
- Browser: Safari, Chrome
- Problem tritt sowohl im lokalen Netz (Client <-> Server nebeneinander) als auch Remote via UMTS auf.

Zusätzlich ist mir bei der Verwendung via UMTS Karte aufgefallen, dass scheinbar eine Menge Daten über die Leitung gingen. Ich hab mein Limit erreicht... Ich kann natürlich nicht sicher sagen, ob dies an dem FHEM Problem liegt, aber jetzt ist der Traffic wieder geringer.

HTH

Gruß
André

[geek]

Hi,

ok, so wie's aussieht muß auch in perl EAGAIN bei sysread()/syswrite() behandelt werden - und IO::Socket::SSL braucht auch ne Sonderbehandlung für non-blocking sockets:

http://search.cpan.org/~sullr/IO-Socket-SSL-1.997/lib/IO/Socket/SSL.pod#Using_Non-Blocking_Sockets

Ist also wie Anfangs angedeutet keine triviale Änderung. Mein einfacher Aufruf von ->blocking(0) war halt wirklich nur "quick'n'dirty" zum Eingrenzen des Hängers. Ehrlich gesagt bin ich überrascht daß es bei mir ohne weiter Änderung funktioniert - Sorry, wenn ich das nicht klar zum Ausdruck gebracht habe und deswegen was kaputt gegangen ist.

sorry
Rainer

(der bis zum überschreiten seiner Schmerzschwelle erstmal wieder longpoll aus hat)

[herrmannj]

Hi,

ich häng mich da mal rein weil ich mich eben auch als Betroffener erkannt habe. Allerdings meine ich das longpoll nur EIN symptom (bzw EINE Auswirkung sind).

Fehler insgesamt: fhem stoppt die Auslieferung von Daten: webif hängt, longpoll hängt ....
(kein ssl, gzip deaktiviert)

* Lokal (lokaler Browser: FF14) am dev-notebook (schnell): Fehler tritt sehr selten auf, so selten das ich den erst als dev Fehler von mir vermutet habe.
* Netzwerk (schnell) an anderem Notebook (sauschnell): Wenn pgm2 "große" Seiten ausliefert hängt pgm2 bereits bei der Seitenauslieferung (spoaradisch, häufig, selbstredend nicht sicher reproduzierbar) stehen. Verbindung offen aber fhem schweigt einfach autistisch. edit & add in der Mitte der Seite
* Floorplan, Netzwerk: Fehler tritt extrem selten auf ( he ? basiert doch auf der gleichen Infrastruktur )
* longpoll: verhält sich analog zum webif: dev-nb: geht meistens. dito floorplan remote (lokal Netz). longpoll im pgm2 Interface: bleibt plötzlich stehen (state 3, also noch offen). Danach Glückspiel: durchaus möglich das einige xx Sekunden später plötzlich die Aktualisierungen nachgereicht werden und die Auslieferung seitens fhem wieder "anspringt".
Gleichzeitig bleibt fhem von anderen clients erreichbar.

Insgesamt recht unbefriedigend und scheinbar auch echt eine never-ending story. 

Die "neue" tcputils.pm halbiert die Fehler Rate (machts also besser), Fehler bleibt jedoch bestehen !!!

vg
Jörg

 

[justme1968]

wenn man in safari 5 oder 6 tabs öffnet bleiben alte und neue tabs komplett hängen und werden erst gefüllt wenn man alte tabs schließt.

gruss
  andre

[hexenmeister]

Das mit 5-6 offenen Tabs habe ich schon lange beobachtet (FireFox).

[herrmannj]

Hi Danke,

wenn man in safari 5 oder 6 tabs öffnet bleiben alte und neue tabs komplett hängen und werden erst gefüllt wenn man alte tabs schließt.

machen alle browser aufgrund einer Beschränkung der offenen connections zu EINEM host. Die zählen pro browser und nicht pro tab!

Als genereller Hinweis gut gemeint jedoch bekannt und beachtet. Mit dem beschriebenen hat das nichts zu tun.

Danke und Grüße
Jörg

[justme1968]

dann müssten aber die schon offenen tabs unverändert weiter laufen. die bleiben aber auch hängen.

gruss
  andre

[herrmannj]

Ah verstehe. Ist das ein fhem spezifisches Verhalten ?

vg
Jörg

[rudolfkoenig]

@geek: kannst Du bitte alarmTimeout testen? Siehe diese Diskussion.

[satprofi]

Hallo.
Bin gerade über diesen Thread gestolpert, auch ich habe Probs mit WebIF. Musste immer per telnet fhem killen u. neustarten.
Habe das ganze zufällig einkreisen können, es lag an "myrss". ich hatte als letzte meldung im log immer "xmllist" als fehler, und eine IP meines tablets.
jetzt habe ich myrss deleted und jetzt klappts bisher ohne hänger schon seit 3h.

ich hoffe es bleibt so.

[satprofi]

hallo.
da heutewieder massenhaft hänger vorhanden, und keiner der tablets rss geladen hatten, bin ich der sache auf den grund gegangen. da kam ich drauf, das ein tablet webviewcontrol noch im hintergrund laufen hatte, das auch diese komische xmllist als cmd sendete. jetzt habe ich webviewcontrol dort beendet und konnte sofort das webif von fhem aufrufen. mal gucken ob dies jetzt für ruhe sorgt.

[geek]

Hi,

sorry für die späte Rückmeldung... bin leider nicht vorher dazu gekommen, zu testen.

Wie zu erwarten verbessert alarm() die Situation, verhindert kurze Hänger aber nicht komplett. Habe also mal geschaut, ob/wie ich das non-blocking hinbekomme ohne was anderes kaputt zu machen. Wie original beschrieben muss bei non-blocking nach jedem syswrite/-read errno geprüft werden... und im Zusammenhang mit SSL entstehen noch weitere Sonderfälle.

Erstmal zum reproduzieren:

Code Auswählen Erweitern


# - longpoll einschalten
# - die neuen SVG icons for on/off nehmen - mit den default png icons gibts nicht genug traffic
define WEB FHEMWEB 8183 global
attr WEB iconPath fhemSVG:openautomation:default
attr WEB longpoll 1
attr WEB longpollSVG 1
attr WEB plotfork 1
define WEBS FHEMWEB 8184 global
attr WEBS HTTPS 1
attr WEBS iconPath fhemSVG:openautomation:default
attr WEBS longpoll 1
attr WEBS longpollSVG 1
attr WEBS plotfork 1

# ein paar dummys anlegen (nicht zu viele - sonst gibs andere Probleme)
define bulk01 dummy
...
define bulk29 dummy

# web-browser aufmachen, "Everything" room anzeigen.

# auf client connections "leise" wegwerfen:
iptables -A OUTPUT -j DROP -p tcp --dport 8183:8184

# per telnet updates erzeugen:
set bulk.* on
set bulk.* off

# fhem hängt, Recv-Q ist randvoll:
# netstat -an | grep 8183
Proto Recv-Q Send-Q Local Address           Foreign Address         State     
tcp        0      0 0.0.0.0:8183            0.0.0.0:*               LISTEN     
tcp        0      0 192.168.2.3:8183        192.168.1.12:51428      ESTABLISHED
tcp        0      0 192.168.2.3:8183        192.168.1.12:51427      ESTABLISHED
tcp        0      0 192.168.2.3:8183        192.168.1.12:51423      ESTABLISHED
tcp        0  53576 192.168.2.3:8183        192.168.1.12:51425      ESTABLISHED
tcp        0      0 192.168.2.3:8183        192.168.1.12:51424      ESTABLISHED
tcp        0      0 192.168.2.3:8183        192.168.1.12:51426      ESTABLISHED



Anbei ist ein Patch der in fhem.pl die Basis für nonblocking Sockets legt und diese erstmal nur in fhemweb  nutzt. Per default lässt sich non-blocking nicht einschalten ohne was kaputt zu machen. Ähnlich wie fhemweb müßten auch in andere module angepasst werden.

Bei mir tuts - auch mit SSL - aber ich wette nicht alle Situationen reproduzieren zu können. Gerade mit SSL ist das recht ... unübersichtlich.

Ich würde also vorschlagen, daß erstmal von ein paar wagemutigen testen zu lassen bevor ein commit in betracht gezogen wird.

Als nächstes würde ich mir das telnet modul anschauen.

BTW: Beim testen hatte ich auch Probleme, wenn der writebuffer schon 102400 Zeichen lang war - addToWritebuffer wirft dann die neuen Daten kommentarlos weg. Das kann bei großen updates (>40 dummys in obigem config Beispiel) auch ohne hängende connection passieren! Da bin ich noch unentschlossen, wie man das "richtig" verbessert.

[rudolfkoenig]

Wo kann ich was ueber want_write und want_read nachlesen?

[geek]

Hi,

in der Doku zu neuerem IO::Socket::SSL gibts die ersten Hinweise: http://search.cpan.org/~sullr/IO-Socket-SSL-2.007/lib/IO/Socket/SSL.pod#Using_Non-Blocking_Sockets (getestet habe ich mit IO::Socket::SSL verision 1.76).

Nach mehrfachem lesen hat mir aber http://stackoverflow.com/questions/3952104/how-to-handle-openssl-ssl-error-want-read-want-write-on-non-blocking-sockets geholfen.

Kurz: Unser select() sagt, daß der TCP socket lese-/schreibfähig ist - weiß aber nicht ob das auch für die dadrüber liegende SSL Session gilt.

Deswegen gibt die SSL Session über den SSL_WANT_READ/_WRITE Umweg zurück, was sie als nächstes tun muß - und bittet uns ihr zu sagen, wann der TCP Socket dafuer bereit ist.

So habe ich das zumindest Verstanden...

Rainer

[rudolfkoenig]

Da wird aber ueberall von SSL_WANT_READ geredet, und du verwendest want_read, und das habe ich nirgendwo gefunden. Und dieses sleep(1) in fhem.pl stoert mich sehr.
Auf wagemutige Tester brauchst du nicht zu hoffen, das ist einer(!) der Gruende, warum ein developer Zweig fuer FHEM zwecklos ist.