Sessions persistantes et réplication de session

Question

J'évalue le cas de l'utilisation de sessions persistantes avec la réplication de session dans tomcat. À partir de mon évaluation initiale, j'ai pensé que si nous activons la réplication de session, la session démarrée dans un nœud tomcat sera copiée sur tous les autres nœuds tomcat et nous n'avons donc pas besoin de session persistante pour continuer les sessions et la demande peut être captée par n'importe quel nœud .

Mais il semble que la réplication de session soit en général utilisée avec des sessions persistantes, sinon l'identifiant de session doit être changé chaque fois que la requête est envoyée à un autre nœud. réf: http://tomcat.apache.org/tomcat-6.0 -doc / cluster-howto.html # Bind_session_after_crash_to_failover_node

Quelqu'un peut-il expliquer quelle est l'utilité réelle de la réplication de session si vous devez activer la session permanente? Parce qu'alors, vous copieriez inutilement la session sur chaque nœud, lorsque la demande avec un identifiant de session donné va toujours au même nœud. Cela pourrait être bénéfique en cas de panne d'un nœud, mais cela ne se produit pas fréquemment et l'utilisation de la réplication de session uniquement pour cela semble être une exagération.

Answer 1

Je pense que le seul réel avantage est de pouvoir arrêter les instances Tomcat sans trop réfléchir.En particulier, cela s'applique aujourd'hui dans le monde du cloud (pensez aux instances ponctuelles Amazon AWS) lorsque les nœuds peuvent s'allumer et s'éteindre très souvent.Une alternative à cela serait d'acheter un équilibreur de charge décent qui prend en charge le drainage des nœuds.Mais les équilibreurs de charge décents coûtent cher et la vidange prend du temps.

Un autre scénario auquel je peux penser est une (mauvaise mise en œuvre du) panier où les articles sont conservés dans le code générique et l'arrêt obligerait l'utilisateur à les racheter (ce qui entraînerait probablement une vente perdue).

Mais dans la plupart des cas, vous avez raison: l'avantage d'avoir à la fois des sessions persistantes et la réplication de session est très négligeable.

Answer 2

Comme Mindas l'a déjà expliqué:

Lorsque vous utilisez l'équilibrage de charge, cela signifie que vous avez plusieurs instances de tomcat et que vous devez diviser les charges.

• Si vous utilisez la réplication de session sans session permanente: imaginez que vous n'avez qu'un seul utilisateur utilisant votre application Web et que vous en avez 3 instances de tomcat. Cet utilisateur envoie plusieurs demandes à votre application, puis l'équilibreur de charge enverra certaines de ces requêtes au premier tomcat instance, et envoyez une autre de ces demandes au deuxième instance, et autre à la troisième.
• Si vous utilisez une session permanente sans réplication: imaginez que vous n'avez qu'un seul utilisateur utilisant votre application Web et que vous avez 3 tomcat instances. Cet utilisateur envoie plusieurs requêtes à votre application, puis le loadbalancer enverra la première demande utilisateur à l'un des trois les instances tomcat et toutes les autres requêtes envoyées par ce l'utilisateur au cours de sa session sera envoyé à la même instance de tomcat. Au cours de ces demandes, si vous arrêtez ou redémarrez ce tomcat instance (instance de tomcat utilisée), l'équilibreur de charge envoie le demandes restantes à une autre instance de tomcat qui est toujours en cours d'exécution, MAIS comme vous n'utilisez pas la réplication de session, l'instance tomcat qui reçoit les demandes restantes n'a pas de copie de la session utilisateur puis pour ce tomcat l'utilisateur commence une session: le l'utilisateur perd sa session et est déconnecté de l'application Web bien que l'application Web est toujours en cours d'exécution.
• Si vous utilisez une session permanente AVEC la réplication de session: imaginez que vous n'avez qu'un seul utilisateur utilisant votre application Web et que vous disposez de 3 tomcat instances. Cet utilisateur envoie plusieurs requêtes à votre application, puis le loadbalancer enverra la première demande utilisateur à l'un des trois les instances tomcat et toutes les autres demandes envoyées par ce l'utilisateur au cours de sa session sera envoyé à la même instance de tomcat. Au cours de ces demandes, si vous arrêtez ou redémarrez ce tomcat instance (instance de tomcat utilisée), l'équilibreur de charge envoie le demandes restantes à une autre instance de tomcat qui est toujours en cours d'exécution, lorsque vous utilisez la réplication de session, l'instance tomcat qui reçoit les demandes restantes a une copie de la session utilisateur puis l'utilisateur continue sa session: l'utilisateur continue à naviguer sur votre site app sans être déconnecté, l'arrêt de l'instance tomcat n'affecte pas la navigation de l'utilisateur.

Answer 3

Juste pour clarifier les problèmes de configuration sur JBoss 5.X dans la configuration de base "all" avec mod_jk.Définition de sessions persistantes dans le fichier workers.properties

 worker.list=loadbalancer

 ... nodes configuration omitted

 worker.loadbalancer.balance_workers=node1,node2
 worker.loadbalancer.sticky_session=True

n'empêche pas la réplication de session.Pour désactiver la réplication de session sur JBoss, nous devons définir le paramètre $ JBOSS_HOME \ server \ YOUR_NODE_NAME \ deploy \ cluster \ jboss-cache-manager.sar \ META-INF \ jboss-cache-manager-jboss-beans.xml cacheMode paramètreà LOCAL.

Habituellement, dans le scénario de session permanente, nous ne voulons pas de réplication de session, car nous ne voulons pas de surcharge supplémentaire liée à une quantité importante d'opérations d'E / S nécessaires pour répliquer les sessions.

En fait, si vous utilisez des sessions persistantes, nous n'avons pas besoin d'exécuter JBoss en configuration "all", nous pourrions utiliser une configuration basée sur "par défaut" ou "standard".

La seule chose à faire est de modifier $ JBOSS_HOME / server / YOUR_NODE_NAME / deploy / jbossweb.sar / server.xml:

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">