v37: Longpolling?

[Frank Niethardt]

Moin,

beim Lesen der Releasenotes ist mir das aufgefallen:

• Umbau Kommunikation: Die Kommunkation vom Client zum Frontendserver erfolgt nicht mehr über Websockets. Relevante Funktionalitäten verwenden nun Long-Polling.

Bedeutet das, dass jetzt statt WebSockets über offen gehaltene HTTP Verbindungen gearbeitet wird? Wenn ja, ist das ein schlechter Ansatz. Browser blockieren bei erstaunlich wenigen dieser offen gehaltenen Verbindungen sämtliche Browserfenster zu diesem Server ohne (für den Anwender) ersichtlichen Grund, bis eins der beteiligten Tabs/Fenster geschlossen werden.

KIX arbeitet jetzt nicht ganz so viel mit Popups und neuen Fenstern, aber das waren nur 4 oder 6 Verbindungen.

Nur als Hinweis aus leidvoller Erfahrung. :)

Viele Grüße
Frank

[sapl]

Moin,

die Gründe würden mich auch interessieren. :)

Ich wäre allerdings zurückhaltender bei der Einschätzung, den Ansatz pauschal als schlecht zu bewerten.
Gerade bei Firewalls, Loadbalancern/ADCs funktionieren Long Polls (in meiner Wahrnehmung) besser als Websockets. Bei KIX kontret haben wir recht lange beraucht, bis es ohne Fallback auf reguläres Polling über den Loadbalancer lief.

Viele Grüße,
sapl

[Torsten Thau]

Hallo, Danke für die Einschätzung. Statt der Websockets wird nun Long-Polling verwendet. Die Websockets sind vor allem wegen folgender Gründe entfallen (einen hat bereits sapl erwähnt):

(1) für die Skalierung des Frontends auf mehrere Container wäre die Beibehaltung der Websockets eine sehr aufwändige und damit teure Option geworden, die zudem noch weitere Risiken bzw. Fehlerquellen (siehe 2) mit sich bringt. 

(2) Mit Sockets gab es immer wieder zu vielen Verbindungsproblemen insb. bei Umgebungen in denen Reverseproxies, VPN-Verbindungen o.ä. für HomeOffice-Szenarien eingesetzt wurden. Dies führte dann zu einer Mischung aus Fehlermeldungen, Rückfall auf HTTP-Polling und resultierte auch in schlechter Performance obwohl eigentlich Ressourcen vorhanden waren. 

Der RC steht jedenfalls bereit (sofern freigeschaltet für ihr Repository, wenn nicht einfach direkte Nachricht) und kann gern getestet werden.

vG, T.Thau

[Torsten Thau]

FYI

Wir haben uns das nochmal angeschaut. Das Problem ist, dass Browser die Anzahl der Requests pro Service/Seite beschränken. Das hätte zur Folge dass ab 6 KIX-Browsertabs mind. eines der KIX-Browsertabs nicht mehr reagieren würde bzw. keine Updates erhält.

Das Verwenden von vielen Browsertabs widerspricht komplett dem Nutzungsansatz von KIX. Denn das mehrfache Laden der KIX-App ist so oder so nicht sinnvoll. Nichtsdestotrotz kann es vorkommen insb. wenn viel auf URLs aus Benachrichtigungsmails geklickt wird, oder wenn im Admin-Bereich gearbeitet wird. 

Es wird daher noch kleine Anpassungen geben:

• es gibt nur einen "Master" KIX-Browsertab, welcher mittels Longpollling Daten empfängt
• wird dieser Master geschlossen, übernimmt eine andere Instanz
• andere KIX-Browsertab-Instanzen werden mittels Broadcast Channel benachrichtigt (Analog zur Redis Nutzung aus Serverseite)
• aktuell gibt es bis zu 3 Longpollings pro KIX-Browsertab-Instanzen, diese werden ggf. auch zu einem Prozess zusammengefasst

Damit sollte das Risiko einer Blockade durch zu viele Browsertabs vermieden werden. Es kann aber passieren das gerade bei schnellem Browser-Tab-Wechsel dann die angezeigten Informationen nicht aktuell sind. Das ist dann leider der Preis für die bessere Stabilität.

vG, T.Thau

[Frank Niethardt]

Moin Torsten,

ich bin nicht prinzipiell dagegen, sondern wollte einfach auf die Problematik hinweisen, die für den Nutzer überhaupt nicht ersichtlich ist. ;)
Die Browser blockieren dann wie gesagt nicht einen Tab, sondern alle, die mit diesem Server offene Verbindungen halten, bis das Limit wieder unterschritten wird.

Ich bin aber bei dir, dass sich bei KIX im Normalfall alles innerhalb eines Tabs abspielt und damit das Risiko eh gering ist...

Viele Grüße
Frank