[KT2L] Das mit Vaadin UI und der HTTP Session

Eigentlich sollte bei einem Refresh im Browser alles weggeworfen werden und es fängt von vorne an. Das ist so auch der Standart wenn man Vaadin nutzt. Genauer wird sogar bei Wechsel der Seite (Routing) immer alles neu geladen. Navigierst du zurück, ist alles weg. Nachteil des Verhaltens ist, dass man keine echte Anwendung bauen kann in der der Status einer Seite, die gerade nicht zu sehen ist, bestehen bleibt. Blöd wenn man z.B. ein Log oder zwei Logs laufen hat und dann mal was anderes schauen will. Huch, Log weg.

Deshalb wurde bei KT2L auf die Fähigkeit verzichtet die Session `serializable` zu halten und somit stateless auf mehreren Instanzen bereit zu stellen: Einmal an einer Instanz angemeldet, musst du dort auch bleiben, sonst ist deine Anwendung weg. Vorteil: im Hintergrund kann die Anwendung schön weiter arbeiten, Logs und Events sammeln,  damit die Ansicht aktuell bleibt.

Solange im Browser nicht 'Refresh' gedrückt wird ist alles gut. Leider hat sich der Teil mit dem Refresh auf der aktuellen Seite auch als problematisch herausgestellt. Im Grunde wird bei jedem Refresh die Session und die Vaadin UI neu erstellt. Bei schwachen Verbindungen kann da schon mal ein Refresh passieren, ohne das man das will. Schwups Anwendung beendet und von vorne.

Zum Glück kann man das umstellen und die Session bei einem Refresh wird nicht mehr gelöscht. Aber auch das hat seine Haken. Denn die Vaadin UI wird schon gelöscht und eine Neue erstellt. Das bedeutet bei jedem Refresh wird jede Referenz auf das UI-Objekt ungültig. Es werden Events geworfen für `Detatch` und `Attach` der UI. Und bei `Detach` können nun auch die Ressourcen (z.B. Log-Watch)  nicht mehr freigegeben werden.

Aber alles halb so schlimm. Wichtig: Bei jeder Aktion, immer, die UI neu holen. Leider kann es passieren das die UI gerade ungültig ist. ggf. sollte das noch abgefangen werden. 

Leider läuft die HTTP Session normalerweise so 180 Minuten.  Wenn im Hintergrund jede Menge Resourcen für die Anwendung gebraucht werden kann das ein Problem werden. Deshalb muss die HTTP Session auf eine viel kürzere Zeit, z.B. 10 Minuten reduziert werden.

Doch jetzt das nächste Problem in der Kette: Ist der User 10 Minuten inaktiv stirbt die aktuelle HTTP Session. Und nun? Die Lösung ist eine Session-Timeout-Benachrichtigung. Sie wird 60 Sekunden vor dem Ende der HTTP Session aktiv und zeigt einen Dialog an 'Achtung die Session läuft gleich ab ...'. Und wenn der Dialog het einen 'Session verlängern' Knopf. Erscheint die Nachricht kann mit JavaScript im Browser der Knopf automatisiert aktiviert werden und so wird die Session automatisch verlängert.

Diese Lösung ermöglicht es die Session zu behalten solange die Anwendung im Browser offen ist und der Browser auch reagiert (z.B. der Rechner nicht eingeschlafen ist). Ausserdem werden Resource innerhalb von 10 Minuten weggeräumt, ist der user nicht mehr da. Und es wird immer wieder kurz ein Dialog angezeigt, wenn der User die Anwendung nicht mehr Bedient. 

Problem gelöst!

Kommentare

Beliebte Posts aus diesem Blog

Sonatype Nexus fails with random "peer not authenticated" errors behind ingress

[mhus lib] Reorg in generation 7 nearly finished

Creating a flux sync configuration referring a config map for substitution