WildFly 10 HA deploy: Sitzungen nicht verlieren

Question

Ich habe den ganzen Tag Beiträge und Dokumentation zu diesem Thema gelesen, und kann immer noch nichts leicht zu verstehen und zu vertrauen.

Ich habe derzeit meine Webapp auf WildFly 10 als einfache War-Datei bereitgestellt.

Es ist eine E-Commerce-Website, in Produktion für ein paar Wochen, und jedes Mal, wenn wir ein neues Release bereitstellen müssen, naja ... das ist sehr ärgerlich, weil einige Kunden gerade einkaufen und die Bereitstellung wird offensichtlich Lass sie ihre Sitzungen verlieren, und das ist sehr schlecht.

Ich brauche eine Lösung, um einen neuen Krieg zu implementieren, ohne den Anwendungsserver neu zu starten. Zuerst lese ich die Dokumente über Clustering (Domänenkonfiguration über Standalone-Konfiguration), aber ich bin mir nicht sicher, dass das für mich genug ist ...

Stellen Sie sich den gleichen Kunden mit ein paar Artikel im Warenkorb (http Sitzung) Zugriff auf den ersten Knoten des Clusters. Dann lege ich es nieder, weil ich mich bereitstelle. OK, der Kunde wird zum zweiten Knoten des Clusters weitergeleitet, aber ... sind die Sitzungsdaten noch verfügbar? Wird er die Einkaufswagen-Artikel "verlieren"?

Ich habe über sticky Sitzungen gelesen, aber nichts über die Konfiguration in WildFly. Ich bin auf Amazon AWS, daher kann ich auch ELB (Load Balancer) verwenden. Können Sie mir helfen, genau zu verstehen, was ich lernen und verwenden muss?

Answer 1

Jede WildFly-Instanz hat ihre eigene Sitzungs-ID, die sie im Cookie behält. Diese ID wird nur die Sitzung auf dem bestimmten Knoten wiederherstellen, von dem sie stammt.

Klebrige Sitzungen bedeuten, dass der ELB den Benutzer immer zu demselben Knoten in Ihrem Cluster umleitet, so dass Ihr Problem nicht ganz gelöst wird.

Einige Dinge denken:

Clustering

Clustering helfen kann (muss nicht Domänenmodus sein). Wenn HA aktiviert ist, wird die Sitzung automatisch zwischen den Knoten übertragen, sodass das Cookie im Client-Browser die Sitzung auf beiden Knoten wiederherstellen kann. Dies hat natürlich das Problem, dass wenn Sie eine der War-Dateien zuerst aktualisieren, Sie möglicherweise ein Objekt haben, das nicht mehr de-serialisiert werden kann, weil es sich geändert hat.

Clustering WF auf AWS ist ein wenig schwierig, weil Sie UDP-Broadcast nicht verwenden können, um einander zu erkennen. Wir verwenden eine Datenbankverbindung, um Knoten zu verfolgen und Clustering durchzuführen.

Ihre eigene Rolle

Eine Option, die Sie tun können, ist Ihre eigene Lösung rollen nur die minimale Menge an Informationen auf dem Client zu halten, wie erforderlich. Etwas wie:

1. Erstellen Sie einen Datensatz in der Datenbank mit einer GUID.
2. stellen Sie die GUID zu einem Cookie
3. Speichern Sie die Einzelteile in ihren Wagen in der Datenbank auf dem GUID basiert
4. einen Filter haben, die für die GUID Cookie überprüft und ihren Wagen jedes Mal, wenn sie die Seite getroffen wiederherstellen.

Ich habe einen Ansatz wie dieses für E-Commerce-Anwendungen in der Vergangenheit verwendet. Es hat einen anderen Nebeneffekt, dass Sie jetzt den Einkaufswagen der Person in Ihrer Datenbank gespeichert haben, und es ist einfach zu sehen, was Leute am Kauf interessiert waren.

Verwenden Tomcat parallel Deployment

Hat Ihre Anwendung einen vollständigen App-Server erforderlich? Wenn es nur auf Servetten basiert, könnten Sie versuchen, Tomcat und seine parallele Bereitstellungsfunktion zu verwenden. Es ermöglicht Ihnen, Ihre neue WAR-Datei über Ihre alte WAR-Datei zu verteilen. Es wird dann weiterhin alte Sitzungen zu dem alten Krieg dienen, aber neue Sitzungen werden zu der neuen Kriegsdatei gehen.

Parallele Bereitstellung ist sehr cool, wenn Ihre App einfach genug ist, um Tomcat zu verwenden.