Que faites-vous des informations de session lors de la mise à l'échelle automatique d'une application Web Java utilisant Tomcat? Alors j'ai cherché.
Fidèle à l'essentiel.
Méthode de configuration d'un cluster dans Tomcat et de réplication de session. Vous utilisez simplement la multidiffusion pour former une appartenance au cluster, non? Cette fois, j'essayais d'utiliser l'environnement AWS, donc je suis resté coincé ici. Le multiplicateur est limité dans le VPC.
Je me demande si Oracle Cloud et IBM Bluemix sont conçus pour Java ici, mais qu'en est-il?
Alors, pourquoi ne pas utiliser la bibliothèque fournie par AWS? : cerises:
https://github.com/amazon-archives/aws-dynamodb-session-tomcat
Cela semble être une extension du gestionnaire persistant, qui est l'un des gestionnaires de session fournis par Tomcat en standard.
Persistent Manager fournit la fonction pour stocker les informations de session dans un stockage externe, et en l'utilisant pour changer l'emplacement de stockage de la session de la mémoire à DynamoDB, il semble qu'il s'agit d'une application sans état et la mise à l'échelle automatique est possible. C'est ça?
Malheureusement, il a été archivé et n'est plus mis à jour. Comme prévu, je voulais éviter de l'adopter à partir de maintenant, j'ai donc décidé de l'utiliser car le README m'a demandé d'utiliser à la place "memcached-session-manager".
https://github.com/magro/memcached-session-manager
Effectuez les réglages en lisant la page wiki SetupAndConfiguration dans le README, et enfin la définition du contexte est la suivante. J'ai fait.
META-INF/context.xml (extrait)
<Manager
className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="redis://redis" sticky="false"
sessionBackupAsync="false"
lockingMode="auto"
requestUriIgnorePattern=".*/uptime_check.html$" />
Il semble que cet attribut empêche les sessions d'être modifiées en même temps en raison d'Ajax, de la navigation par onglets, etc. et de la perte des mises à jour.
Vous pouvez spécifier l'URL qui a la possibilité avec une expression régulière, mais comme il était difficile de spécifier exactement où elle se trouvait dans l'application cible cette fois, je l'ai réglée sur "auto".
On dit que cela ne se verrouille pas dans le cas d'une requête en "lecture seule", mais spécifiquement la session n'a pas été accédée du tout (`HttpSession # getAttribute ()` `et` `HttpSession # setAttribute" () `` Non '') semble être le cas.
Si l'URL de la demande correspond à l'expression régulière spécifiée par cet attribut, il semble que le processus d'enregistrement de la session dans la base de données en mémoire puisse être ignoré.
Pour la page (uptime_check.html) où l'équilibreur de charge effectue une vérification de l'état, les informations de session ne sont pas générées, je les ai donc définies comme une URL de saut pour éviter tout traitement inutile.
De plus, l'accès aux fichiers statiques comme celui de l'Exemple a été défini au début car la session n'est pas pertinente, mais cette fois, l'application cible s'est comportée de manière inattendue, j'ai donc décidé de la modifier.
L'application cible a été conçue pour transmettre ServletFilter même pour les fichiers statiques, mais dans cette bibliothèque, chaque fois que `` HttpServletRequest # getSession () '' est appelé dans une requête qui correspond à requestUriIgnorePattern, c'est nouveau. L'implémentation consistait à générer une session, ce qui faisait basculer l'ID de session à chaque fois qu'un fichier statique était accédé, et le comportement de l'application était étrange.
Une erreur de temporisation se produit maintenant après une petite charge. Pour le moment, je l'ai étendu à environ 1,5 seconde et le problème a été résolu, mais je doute que ce soit correct. : en pensant:
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)
Lors de la génération d'un ID de session, Tomcat recherche la mémoire et se régénère si l'ID de session est en conflit.
Cette bibliothèque semble effacer les informations de session de la mémoire et les enregistrer dans la base de données en mémoire, il est donc possible que l'ID de session ne soit pas unique. J'étais inquiet.
… L'auteur ne se heurte pas tellement, alors je m'en soucie trop. Vous dites (Problèmes GitHub)
Recommended Posts