Ich nutze auf einem Android-Tablet die App webviewcontrol in Kombination mit der html-Ausgabe von 02_RSS.pm. Darin gibt es einen meta refresh, um die Seite regelmäßig zu aktualisieren. Bisher lief das völlig problemlos.
Seit ein paar Stunden funktioniert der refresh nur noch maximal 15 Minuten, danach erfolgt keine Aktualisierung mehr. Am Tablet wurde nichts geändert. In fhem finde ich auch keine Anhaltspunkte, woher das kommen könnte.
Hat irgendwer eine Idee, wo man da suchen soll?
(Tipps wie Cache löschen usw. sind nicht zielführend, solche Maßnahmen habe ich alle schon mehrfach durchexerziert)
Das Ganze scheint ein "neues" Performance-Problem von fhem zu sein, aber ich komme der Ursache nicht auf die Spur.
Mit Webseiten von anderen Webservern funktioniert der refresh völlig problemlos.
Muss ich mir heute Abend mal anschauen.
Ich nutze die PNG-Ausgabe und binde die in ein eigenes html-Gerüst mit Refresh ein; das läuft einwandfrei.
Daher sollte der Unterschied woanders liegen.
Die html-Ausgabe des RSS bindet ja auch das PNG ein, nur halt direkt mit html-Tags.
Hast Du da noch irgendwelche Anpassungen mit drin?
Hi,
kann eine Variante des beschriebenen Verhaltens bestätigen mit folgenden Symptomen bestätigen:
wiederholter refresh: fhemweb nimmt die Anfrage entgegen, liefert aber keine (nur teilweise) Daten aus (Verbindung bleibt offen, client wartet). Das Verhalten ist auch schon länger zu beobachten, meiner Beobachtung nach spielt die Menge der auszuliefernden Daten eine Rolle wann der Effekt eintritt. Man schafft das auch mit dem longpoll wenn man genügend Daten verschickt.
vg
Jörg
Wenn du mir was zum Nachstellen zeigst, dann versuche es zu debuggen.
Hilft closeConn als Workaround?
Hi,
Hilft closeConn als Workaround?
nö, war auf meinem dev nb scheinbar von früheren Test sowie an.
Das poc device im Anhang schreibt 1MB Nutzlast in die fw_detail, das macht es einfacher. In der detail view wiederholt f5 drücken. Das webif hängt (bei mir) recht sicher nach ein bis zwei dutzend refresh.
OS ist ubuntu auf einem 1,73 centrino
vg
jörg
Bei mir geht es nicht so einfach. Habe bei 100 aufgehoert:
strace -tt -p mit tail -100. Jetzt musste ich aber auch recht oft drücken. Er hängt in einem select. Wie liest man die Werte in den geschweiften Klammern ?
Zitat von: herrmannj am 01 November 2014, 01:42:02
strace -tt -p mit tail -100. Jetzt musste ich aber auch recht oft drücken. Er hängt in einem select. Wie liest man die Werte in den geschweiften Klammern ?
edit: verstanden. timeout "fast" 5 sekunden. Während ich gerade schrieb habe ich den Prozess leben lassen. Stand jetzt, also 20min ++
gerade eben nochmal den strace angehangen. Da sehe ich das der select weiter aufgerufen wird. Das webif ist von der maschine aus wo ich es ausprobiert habe weg, von einer anderen aus gehts.
browser zu, kurz warten und wieder auf scheint auch zu helfen. Gab es eigentlich in den letzten Wochen nochmal Änderungen diesbezüglich? Ich habe vor dem Test nochmal ein fhem update gemacht und es scheint mir seltener aufzutreten, weg ist aber nicht.
Nach der ganzen Prozedur leg ich mich mal auf eine Theorie fest. Kann es sein das fhemweb close nicht abarbeitet wird ?
So was:
$rv = $sock-->recv($msg, POSIX::BUFSIZ,0);
unless (defined($rv) && length $msg) {
$sock->close(); # und raus aus der selectlist ...
}
ZitatWährend ich gerade schrieb habe ich den Prozess leben lassen. Stand jetzt, also 20min ++
Dann ist entweder strace kaputt oder das linux select.
ZitatGab es eigentlich in den letzten Wochen nochmal Änderungen diesbezüglich?
Ich erinnere mich an keine.
ZitatKann es sein das fhemweb close nicht abarbeitet wird ?
FHEMWEB macht nur mit gesetzten closeConn die Verbindung zu, da es normalerweise nicht notwendig ist, nur fuer iPhones/iPads in manchen Konfigurationen. Dass beim gesetzten closeConn die Verbindung nicht immer geschlossen wird, mag zwar sein, finde ich aber nicht sehr wahrscheinlich.
ZitatDann ist entweder strace kaputt oder das linux select.
Wieso? Die scheinen doch beide das zu machen was sie sollen ? fhem bedient die Verbindung zum browser nicht mehr.
Brauchst Du was andere ?
vg
Die letzte Zeile in deinem log war:
Zitat01:33:27.108751 select(32, [6 7 8 9 10 14 16 17 18 19 20 21 22 23 24 25 26 27 28 29], NULL, NULL, {4, 891676} <unfinished ...>
Und du sagst:
ZitatWährend ich gerade schrieb habe ich den Prozess leben lassen. Stand jetzt, also 20min ++
Habs vermutlich nicht richtig zusammengereimt. Damit waere ich wieder am Ausgangspunkt: kein Plan.
ok, ist Missverständlich.
Ich hab den strace gestartet. Dann f5 bis nix mehr ging, warten, strace aus und tail -100 auf das strace log.
Letzte Position im log. Dann hab ich mich nicht mehr um den fhem Prozess gekümmert, aus Sicht des webifs war er gestorben.
Die 20min++ Erkenntnis war nun dass "nur" das webif nicht mehr reagiert, auch nicht auf abbrechen und neu laden. Die fhem loop (das select) wird weiterhin aufgerufen und scheint auch korrekt zu arbeiten.
Was ich nicht sehe ist ob es zwischen dem ersten strace und dem zweiten eine pause gab wo er vielleicht in einem sysread oder write hing. Um das webif zu reanimieren war in diesem Fall ein schließen den browser fensters, kurz warten und neu starten ausreichend.
(Ich erinnere mich aber auch an viele Fälle wo ich schwören kann dass das nicht gereicht hat).
Vielleicht kann betateilchen ja auch ein strace von seinem refresh prob reinwerfen.
neuerlicher Hänger im webif, kein reload, kein ctrl f5.
Login von anderer Maschine, alle fhemweb Instanzen gelöscht und siehe da, es ging weiter ...
Funktioniert es im Problemfall nach einem Browser-Neustart?
Und was fuer ein Client verwendest Du, dass du auf eine Maschine wechseln musst?
iOS ist bekannt fuer ein aehnliches Problem, wo mehrere Browser Neustarts erforderlich sind, bis es funktioniert, und da habe ich iOS im Verdacht. Ich wuerde auch ein workaround einbauen, wenn ich wuesste, woran es genau liegt.
browser ist firefox auf beiden Rechnern. Ein löschen der fhemweb instanzen hat geholfen.
Zitatda habe ich iOS im Verdacht.
fragt sich was Ursache und was Wirkung ist