Was tun Sie mit Sitzungsinformationen, wenn Sie eine Java-Webanwendung, die Tomcat verwendet, automatisch skalieren? Also habe ich nachgeschlagen.
Getreu den Grundlagen.
Eine Methode zum Einrichten eines Clusters in Tomcat und zum Durchführen der Sitzungsreplikation. Sie verwenden nur Multicast, um eine Cluster-Mitgliedschaft zu bilden, oder? Dieses Mal habe ich versucht, die AWS-Umgebung zu verwenden, also bin ich hier festgefahren. Der Multiplikator ist innerhalb der VPC beschränkt.
Ich befürchte, dass Oracle Cloud und IBM Bluemix hier Java-freundlich aufgebaut sind, aber was ist damit?
Dann nutzen Sie doch die von AWS bereitgestellte Bibliothek. : Kirschen:
https://github.com/amazon-archives/aws-dynamodb-session-tomcat
Dies scheint eine Erweiterung des persistenten Managers zu sein, der einer der von Tomcat standardmäßig bereitgestellten Sitzungsmanager ist.
Persistent Manager bietet die Funktion zum Speichern von Sitzungsinformationen in einem externen Speicher. Wenn Sie damit den Speicherort der Sitzung vom Speicher in DynamoDB ändern, scheint es sich um eine zustandslose Anwendung zu handeln, und eine automatische Skalierung ist möglich. Ist es?
Leider wurde es archiviert und wird nicht mehr aktualisiert. Wie erwartet wollte ich es von nun an vermeiden, es zu übernehmen, und entschied mich daher, es zu verwenden, da die README-Datei mich aufforderte, stattdessen "memcached-session-manager" zu verwenden.
https://github.com/magro/memcached-session-manager
Nehmen Sie die Einstellungen vor, während Sie die SetupAndConfiguration-Wiki-Seite in der README-Datei lesen. Schließlich lautet die Definition des Kontexts wie folgt. Ich tat.
META-INF/context.xml (Auszug)
<Manager
className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="redis://redis" sticky="false"
sessionBackupAsync="false"
lockingMode="auto"
requestUriIgnorePattern=".*/uptime_check.html$" />
Es scheint, dass dieses Attribut verhindern soll, dass Sitzungen gleichzeitig geändert werden, weil Ajax, das Durchsuchen von Registerkarten usw. und Aktualisierungen verloren gehen.
Sie können eine URL angeben, für die dies mit einem regulären Ausdruck möglich ist. Da es diesmal jedoch schwierig war, genau anzugeben, wo sie sich mit der Zielanwendung befand, habe ich sie auf "auto" gesetzt.
Es wird gesagt, dass dies bei einer Anforderung, die "schreibgeschützt" ist, nicht gesperrt wird, aber speziell auf die Sitzung überhaupt nicht zugegriffen wurde (`HttpSession # getAttribute ()` und HttpSession # setAttribute " Es scheint, dass der Fall () nicht erledigt wurde) das Ziel ist.
Wenn die URL der Anforderung mit dem durch dieses Attribut angegebenen regulären Ausdruck übereinstimmt, kann der Prozess des Speicherns der Sitzung in der speicherinternen Datenbank anscheinend übersprungen werden.
Für die Seite (uptime_check.html), auf der der Load Balancer eine Integritätsprüfung durchführt, werden keine Sitzungsinformationen generiert. Daher habe ich sie als Überspring-URL festgelegt, um unnötige Verarbeitung zu vermeiden.
Außerdem wurde der Zugriff auf statische Dateien wie in Beispiel zunächst festgelegt, da die Sitzung irrelevant ist. Diesmal hat sich die Ziel-App jedoch unerwartet verhalten, sodass ich beschlossen habe, sie zu ändern.
Die Zielanwendung wurde entwickelt, um ServletFilter auch für statische Dateien zu übergeben. In dieser Bibliothek ist es jedoch neu, wenn `HttpServletRequest # getSession ()` in einer Anforderung aufgerufen wird, die mit requestUriIgnorePattern übereinstimmt. Die Implementierung bestand darin, eine Sitzung zu generieren, die dazu führte, dass die Sitzungs-ID bei jedem Zugriff auf eine statische Datei gewechselt wurde und das Verhalten der App seltsam war.
Nach einer kleinen Last tritt nun ein Timeout-Fehler auf. Vorerst habe ich es auf ca. 1,5 Sekunden verlängert und das Problem wurde gelöst, aber ich bezweifle, dass es in Ordnung ist. : Denken:
30-Oct-2018 07:04:51.146 WARNING [http-nio-8080-exec-1] de.javakaffee.web.msm.BackupSessionTask.handleException Could not store session 3EE38D05C62D287516AD504BFCBD572D in memcached.
Note that this session was relocated to this node because the original node was not available.
java.util.concurrent.TimeoutException
at java.util.concurrent.FutureTask.get(FutureTask.java:205)
at de.javakaffee.web.msm.BackupSessionTask.storeSessionInMemcached(BackupSessionTask.java:235)
at de.javakaffee.web.msm.BackupSessionTask.doBackupSession(BackupSessionTask.java:198)
at de.javakaffee.web.msm.BackupSessionTask.call(BackupSessionTask.java:119)
at de.javakaffee.web.msm.BackupSessionTask.call(BackupSessionTask.java:50)
at de.javakaffee.web.msm.BackupSessionService$SynchronousExecutorService.submit(BackupSessionService.java:345)
at de.javakaffee.web.msm.BackupSessionService.backupSession(BackupSessionService.java:204)
at de.javakaffee.web.msm.MemcachedSessionService.backupSession(MemcachedSessionService.java:1098)
at de.javakaffee.web.msm.RequestTrackingHostValve.backupSession(RequestTrackingHostValve.java:232)
at de.javakaffee.web.msm.RequestTrackingHostValve.invoke(RequestTrackingHostValve.java:161)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:800)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Beim Generieren einer Sitzungs-ID durchsucht Tomcat den Speicher und wird neu generiert, wenn die Sitzungs-ID in Konflikt steht.
Diese Bibliothek scheint die Sitzungsinformationen aus dem Speicher zu löschen und in der speicherinternen Datenbank zu speichern, sodass die Sitzungs-ID möglicherweise nicht eindeutig ist. Ich war besorgt.
… Der Autor kollidiert nicht so sehr, deshalb ist mir das zu wichtig. Sagst du (GitHub-Probleme)
Recommended Posts