CometVisu auf weiterer Hardware

[Chris M.]

Das mag das Symptom reduzieren - aber nicht lösen. Wenn sich nämlich der Client einfach so verabschiedet (z.B. Runterfahren) passiert genau das gleiche...

Daher müssen beide Seiten robust darauf reagieren, dass der andere sich mit Ankündigung oder still verabschiedet.

Der Timeout sollte so hoch sein, das er normalerweise nicht auftritt (denn das Wiederherstellen kostet ja auch nur Ressourcen). Andererseits natürlich so kurz, dass eine gestorbene Verbindung nicht wirklich auffällt.
Außerdem sollte das Client Timeout kürzer sein, als das auf dem Server, denn der Client baut ja die Verbindungen auf und sollte daher das Heft in der Hand haben.

[derwolff2010]

Ich habe die Timeoutzeit in der cometvisu-client.js mal von 60 auf 310 Sek. erhöht.
Es gibt keine Verbindungsabrüche mehr und da der eibread-cgi Prozess den Timeout nach 300 Sek. auslöst kommt es nicht mehr zu den toten read-Prozessen. Für mich sieht das jetzt stimmiger aus.

Gibts es bestimmte Gründe warum die Zeit auf 60 Sek. festgelegt wurde?

[Chris M.]

Auf dem CV Demoserver liegen die Antwortzeiten auch deutlich unter 60 Sek. . Kommen wirklich so viele Telegramme über den Bus, die für die Visu relevant sind?
In meiner Version von eibread-cgi wird wirklich nur dann eine Anwort gesendet wenn der Wert des aktuellen Telegramms von der Visu benutzt wird, alles andere wird unterdrückt bis zum Timeout. Es soll ja nicht gepollt werden ;-) . Deshalb kommen mir die Zeiten auf dem Demoserver etwas kurz vor.
Wahrscheinlich sieht man auch deshalb dort nicht den beschrieben Abbruch.

Naja, man kann ja im Firebug mal nachschaun, was da so übertragen wird. Wenn es lauter verschiedene Pakete sind, dann ist auf diesem System anscheinend einfach eine hohe Last (was mich nicht wundern würde).

Bei mir hier z.B. sehe ich durchaus die Timeouts - die sind aber auch (s.o.) durchaus gewollt.

Ich bin durch meine Anpassung immer etwas verunsichert ob dies noch ein Bug in CV ist, oder ob dies nur mich betrifft.

Das kann natürlich beides sein.

Timeouts mit dem "r" sind aber völlig normal.

[derwolff2010]

Auf der Backendseite habe ich eine angepasste Version von eibread-cgi laufen. Der Standardtimeout ist wie im Orginal 300 Sek. oder man gibt einen Wert über den Parameter t mit. Der Rest ist eins zu eins aus dem SVN.

Auf dem CV Demoserver liegen die Antwortzeiten auch deutlich unter 60 Sek. . Kommen wirklich so viele Telegramme über den Bus, die für die Visu relevant sind?
In meiner Version von eibread-cgi wird wirklich nur dann eine Anwort gesendet wenn der Wert des aktuellen Telegramms von der Visu benutzt wird, alles andere wird unterdrückt bis zum Timeout. Es soll ja nicht gepollt werden ;-) . Deshalb kommen mir die Zeiten auf dem Demoserver etwas kurz vor.
Wahrscheinlich sieht man auch deshalb dort nicht den beschrieben Abbruch.

Ich bin durch meine Anpassung immer etwas verunsichert ob dies noch ein Bug in CV ist, oder ob dies nur mich betrifft. Bei dem Diagramm-Plugin habe ich auch noch etwas eingenartiges geloggt, aber leider hat sich noch kein anderer User dazu geäußert.

[Chris M.]

Die CV bricht selber eine Verbindung nach einer gewissen Zeit (müsste nachsehen ob's jetzt eine oder fünf Minuten waren...) ab, um sicher zu gehen, dass nicht nur das Backend ein Problem hat.

=> Die Implementierung des Backends muss das abkönnen.

Aber anders herum geht das genau so: das Backend kann intern einen Timeout haben (optimaler Weise etwas über dem vom Client) und dann die Verbindung und ggf. sich selbst beenden.

Damit sollte sich das leicht lösen lassen.

[derwolff2010]

Hallo,

bei mir läuft die Cometvisu auf einem Dockstar und ist experimentell an ein anderes Bussystem als KNX angebunden.
Grundsätzlich läuft auch alles, mir fällt nur auf dass anscheinend lighttpd sporadisch die Verbindung abbricht ohne dass die Timeoutzeit abgelaufen ist.
Es häufen sich dann bei mir entsprechend viele read-Prozesse an, da die Visu nach einem Abbruch eine neue Anfrage stellt.

Muss noch ein Parameter in der lighttpd Konfiguration für das Keep-Alive Handling gesetzt werden? Oder hat jemand eine Idee woran dies sonst noch liegen kann?

Gruß
Carsten

[Merlin123]

AW: CometVisu auf weiterer Hardware

Ich habe mein Problem in diesen Thread ausgelagert.

[Merlin123]

AW: CometVisu auf weiterer Hardware

Fastcgi war nicht geladen. Die Meldungen sind jetzt weg.
Jetzt mal schauen was geht. Ich glaube mein eibd mag noch nicht...

Gruß,
Oliver

Gesendet via Tapatalk

[Merlin123]

AW: CometVisu auf weiterer Hardware

Guter Hinweis....
Nein. Php tut nicht
Mal schauen ob ich rausfinde wieso. Nehme Tipps dankend an.

Gruß,
Oliver

Gesendet via Tapatalk

[Chris M.]

Erst mal grundsätzlich: funktioniert dort PHP überhaupt?

[Merlin123]

so... also Firebug meint (CV 0.6.2 auf Raspberry Pi mit Lighttpd als Webserver)
Bei der Check config macht der Browser ein get check_config.php und bekommt einen 403er Fehler zurück. (URL http://192.168.0.127/visu/check_config.php)
Die Permissions auf der Datei sind 755.

Beim Aufruf des Editor versucht er die Dateien zu laden:
-rw-rw-r-- 1 www-data www-data 1193 Dec 30 2011 get_addresses.php
-rw-rw-r-- 1 www-data www-data 1005 Dec 30 2011 get_widget_diagram.php
Beide Male kommt auf ein 403er Fehler

Beim Versuch die Konfig zu speichern mal er einen POST auf diese Datei
-rw-rw-r-- 1 www-data www-data 6112 Dec 30 2011 save_config.php
und bekommt auch den 403er Fehler

Welche Permissions müssten die Sachen den haben?

[Merlin123]

AW: CometVisu auf weiterer Hardware

Ah ok.
Ich werde es heute nicht mehr schaffen das mut Firebug zu testeb. Die kids halten mich auf Trab
Schau mir das aber nochmal an.

Gruß,
Oliver

Gesendet via Tapatalk

[Chris M.]

Gerade bei den CV Meldungen frag ich mich, wie ich da im Browser was sehen soll. Die werden doch innerhalb von CV generiert und nur an den Browser ausgeliefert, oder?

Die CV läuft komplett im Browser.

Auf dem Server braucht's neben irgend einem HTTP-Server nur noch die eibd-Anbindung - und selbst die ist nur ein CGI-BIN für den HTTP-Server das bisschen JSON erzeugt.
Für den Editor kommt bisschen PHP oben drauf, aber eigentlich auch nur, damit der im Dateisystem agieren kann.

[Merlin123]

ok. ich schau mal ob ich da heute abend was finde....

Wie gehe ich da am besten vor um sinnvolle Ergebnisse zu bekommen?
Firbug starten, dann die Seiten aufrufen und in Firebug schauen ob was auffällt?

Gerade bei den CV Meldungen frag ich mich, wie ich da im Browser was sehen soll. Die werden doch innerhalb von CV generiert und nur an den Browser ausgeliefert, oder?

[swiss]

Stimmt. Das müsste so auf jeden fall funktionieren... Keine Ahnung. Ohne firebug wird es schwer den Fehler zu finden. Die Palette reicht von "kein schreibzugriff" bis zu fehlenden Pakete für den Interpreter