Universalclient

[Chris M.]

Nun, das ganze muss so robust sein, dass man ständig die Verbindung neu aufbauen kann. (Ist ansonsten so wie ein Backup Recovery das man nie getestet hat...).

Wenn das stabil ist, dann kann man aus Performance-Sicht die Zeiten natürlich bei SSE stark aufweiten.

Beim Long-Pollinng hat man typischer Weise einen 300 Sekunden Time-Out auf der Server-Seite. Daher macht der Client vorher (aktuell 60 Sekunden) proaktiv ein Reconnect. Die Zeit ist schon sehr lange drinnen, da sich bisher niemand daran gestört hat, auch wenn z.B. 400 Sekunden sicher auch funktioniert.
Wenn beim SSE die Verbindung als dauerhaft offen spezifiziert ist und kein Server-Timeout die Verbindung schließt, dann können die 60 Sekunden für den maxConnectionAge natürlich weit geöffnet werden.
Der maxDataAge hat einen anderen Hintergrund: wenn ich die Daten neu lade und eine lange Zeit war da zwischen (z.B. weil der Browser schlafen war), dann kann es sein, dass die Updates seit dem letzten Index nicht mehr reichen - es könnte ja ein Überlauf des Index passiert sein. Daher muss die Zeit hier so eingestellt sein, dass auch unter Worst-Case Bedingungen einer "Index-Kollision" zuvor gekommen wird.

[peuter]

Hab gerade noch zwei grobe Fehler gefunden:
- isConnectionRunning() hat true zurückgegeben wenn die Verbindung geschlossen war, also genau das falsche
- wenn das Backend geändert wird sollten die übergebenen Wert immer mit den default-settings gemerged werden (damit z.B. maxConnectionAge als default-Wert vorhanden ist)

Bisher war z.B. bei openhab2 maxConnectionAge undefined und isConnectionRunning() immer false -> somit hat der Watchdog die Verbindung jedesmal neu gestartet.

Habe das jetzt alles soweit gefixt. Jetzt müsste man mal ein paar Langzeittests machen.

[peuter]

tuxedo
Hast Du schon mal die Zeit gefunden die aktuelle Version gegen Dein Backend zu testen? Wenn dort auch keine Probleme auftreten wäre es an der Zeit mal zu überlegen, was noch getan werden muss oder ob man schon einen Pull request gegen develop stellen kann.

[tuxedo]

Nein, leider noch nicht. Urlaub und Familie hatten bis heute Priorität. Ich schau dass ich's kommende Woche mal durchteste.

[Chris M.]

Wenn dort auch keine Probleme auftreten wäre es an der Zeit mal zu überlegen, was noch getan werden muss oder ob man schon einen Pull request gegen develop stellen kann.

Ich überlege, ob wir nicht vorher noch die 0.9.1 raus bringen sollten. So haben wir länger Zeit diesen ganz Zentralen Teil der CometVisu in der Breite zu testen.
Was haltet ihr davon?

[peuter]

Wäre dann sicherlich sinnvoll erstmal zu releasen um dann mehr Zeit zum Testen zu haben.

[tuxedo]

Sorry dass ich hier so lange nicht mehr aktiv war. Das Thema Visu ist - weil es erstmal so recht gut lief - zeitweise wieder in den Hintergrund gerückt, wird aber gerade wegen einer Kleinigkeit wieder aktuell.

Jetzt wollte ich mal schauen wie es um den "Universal Client" steht und sehe, dass nicht nur 0.9.1 raus ist, sondern auch schon 0.9.2.

Einen direkten Hinweis dass CV nun mit einem "universal client" läuft hab ich nicht gefunden, der PR von peuter ist ja mittlerweile auch gelöscht und hat wohl keinen direkten merge erfahren (--> https://github.com/CometVisu/CometVisu/pull/227)?!

Kurzum: Was ist denn der aktuelle Stand bzgl. SSE und "autoconfig"?

[Chris M.]

Der letzte Kommentar dort sagt

Further development happens in new feature branch 'universal-client' in the CometVisu repository

und ist vollkommen richtig:

Wir hatten einen Branch erstellt, da drinnen den Universal Client entsprechend voran getrieben und schon vor einiger Zeit im Git HEAD gemerged. D.h. die nächste größere Version (Arbeitstitel: 0.10) enthält den Universal Client.

[tuxedo]

Den Kommentar hatte ich gesehen, aber den Branch dann nicht gefunden. Jetzt weiß ich auch wieso... ist schon gemerged.

Danke für's Feedback. Dann schau ich in den Head mal genauer rein.