[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

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

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

 After installing nexus3 server in a kubernetes environment in the first view everything looks good. Server is running an accessible from the world. Users and roles are defined and working. But already in the first hours of working with the repository there are problems. The trick was retry the failed activity and everything went ok. It turned out that heavy activities failed a lot of times and a lot of retries have to be done to finish the tasks. Annoying if a release deploy failed. You need to increase the version number every time. There were a few support in the internet for the problems most of the time handling SSL problems between maven and nexus. But it did not fix the problem. It looks like maven and the used http library wagon have got problems with pooled connections if using ingress (a test with a standalone installation did not show the problem)  - The 'deep' reason is not really clear for me, need to invest more time for it. The solution is to deny wagon to use po
Mehr anzeigen

Creating a flux sync configuration referring a config map for substitution

 If you configure your k8s cluster with terraform one of the final steps is to install a fluxcd operator. The operator are responsible to manage the resources inside of the cluster. In this way a fully automatic creation process is possible. To install flux a terraform provider is available preparing a install and sync configuration which can be installed in k8s using the kubernetes/kubectl providers. In fluxcd itself it is possible to use substitution . This means you can use variables to prepare the k8s yaml files. This is useful for variable content like different cluster names and domain names for all stages. Or more specialised arn ids of created resources while creating the cluster in aws. To use substitution fluxcd offers to link the configuration to a config map. In the map a set of key values can be defined to replace variable values. The map can also be created with terraform and the kubectl provider. Do not store secrets in the config map. Try to use secrets instead. Applyi
Mehr anzeigen

[mhus lib] Reorg in generation 7 nearly finished

 The generation 7 shows massive reorganisations and reimplementations. After renaming repository names (moved the 'cherry' prefix to 'mhus') the reorg is finished and the sources are ready for a more stable generation 8. Generation 8 will add new features to work with none OSGi services in cloud environments. Actual changes: cherry-reactiive -> mhus-reactive cherry-vault -> mhus-vault cherry-web -> mhus-web mhus-osgi-cluster -> mhus-cluster
Mehr anzeigen