session - tomcat 8 cluster

Sesiones adhesivas y replicación de sesiones

Question

Estoy evaluando el caso de usar sesiones rápidas con la replicación de la sesión en Tomcat. Desde mi evaluación inicial, pensé que si habilitamos la replicación de la sesión, entonces la sesión iniciada en un nodo tomcat se copiará a todos los demás nodos tomcat y, por lo tanto, no necesitamos una sesión fija para continuar las sesiones y cualquier nodo puede recoger la solicitud .

Pero parece que la replicación de la sesión se usa en general con las sesiones adhesivas, de lo contrario, la identificación de la sesión debe cambiarse cada vez que la solicitud va a algún otro nodo. ref: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node

¿Alguien puede explicar cuál es el uso real de la replicación de la sesión si tiene que habilitar la sesión fija? Debido a que entonces estaría copiando innecesariamente la sesión en cada nodo, cuando la solicitud con un identificador de sesión dado siempre vaya al mismo nodo. Podría ser beneficioso en el caso de que un nodo se bloquee, pero eso no sucede con frecuencia y el uso de la replicación de la sesión solo parece una exageración.

Answer 1

Como Mindas lo explicó antes:

Cuando usa el equilibrio de carga, significa que tiene varias instancias de Tomcat y necesita dividir las cargas.

• Si está utilizando la replicación de sesión sin sesión fija: imagine que solo tiene un usuario utilizando su aplicación web y tiene 3 instancias de Tomcat. Este usuario envía varias solicitudes a su aplicación, luego el loadbalancer enviará algunas de estas solicitudes a la primera instancia de Tomcat, y enviará algunas de estas solicitudes a la segunda instancia, y otras a la tercera.
• Si está utilizando una sesión fija sin replicación: imagine que solo tiene un usuario utilizando su aplicación web y tiene 3 instancias de Tomcat. Este usuario envía varias solicitudes a su aplicación, luego el loadbalancer enviará la primera solicitud de usuario a una de las tres instancias de tomcat, y todas las demás solicitudes que este usuario envíe durante su sesión se enviarán a la misma instancia de tomcat. Durante estas solicitudes, si apaga o reinicia esta instancia de tomcat (la instancia de tomcat que se usa), el loadbalancer envía las solicitudes restantes a otra instancia de tomcat que aún se está ejecutando, PERO como no usa la replicación de la sesión, la instancia de tomcat que recibe Las solicitudes restantes no tienen una copia de la sesión del usuario, entonces para este tomcat el usuario comienza una sesión: el usuario pierde su sesión y se desconecta de la aplicación web, aunque la aplicación web todavía se está ejecutando.
• Si está utilizando una sesión fija CON la replicación de sesión: imagine que solo tiene un usuario utilizando su aplicación web y tiene 3 instancias de tomcat. Este usuario envía varias solicitudes a su aplicación, luego el loadbalancer enviará la primera solicitud de usuario a una de las tres instancias de tomcat, y todas las demás solicitudes que este usuario envíe durante su sesión se enviarán a la misma instancia de tomcat. Durante estas solicitudes, si apaga o reinicia esta instancia de tomcat (la instancia de tomcat que se usa), el loadbalancer envía las solicitudes restantes a otra instancia de tomcat que aún se está ejecutando, a medida que usa la replicación de la sesión, el tomcat de la instancia que recibe las solicitudes restantes tiene una copia de la sesión del usuario, luego el usuario continúa en su sesión: el usuario continúa navegando por su aplicación web sin ser desconectado, el cierre de la instancia de Tomcat no afecta la navegación del usuario.

Answer 2

Creo que el único beneficio real es poder cerrar las instancias de Tomcat sin pensar mucho. Especialmente esto se aplica hoy en el mundo de la nube (piense en las instancias de Amazon AWS) cuando los nodos pueden activarse y desactivarse con mucha frecuencia. Una alternativa a esto sería comprar un equilibrador de carga decente que admita el drenaje de nodos. Pero los balanceadores de carga decentes son caros, y el drenaje lleva tiempo.

Otro escenario que se me ocurre es una (implementación deficiente) de un carrito de compras donde los artículos se mantienen en HttpSession y el cierre requeriría que el usuario los volviera a comprar (lo que probablemente conduciría a una venta perdida).

Pero en la mayoría de los casos, tiene razón: el beneficio de tener sesiones pegajosas y replicación de sesiones es muy insignificante.

Answer 3

Solo para aclarar los problemas de configuración en JBoss 5.X en "todos" la configuración básica con mod_jk. Configurando sesiones pegajosas en el archivo workers.properties

 worker.list=loadbalancer

 ... nodes configuration omitted

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

no impide la replicación de la sesión. Para desactivar la replicación de sesiones en JBoss, debemos establecer en $ JBOSS_HOME / server / YOUR_NODE_NAME / deploy / cluster / jboss-cache-manager.sar / META-INF / jboss-cache-manager-jboss- cacheMode parámetro de cacheMode a LOCAL .

Por lo general, en el escenario de sesión fija, no queremos la replicación de la sesión, ya que no queremos una sobrecarga adicional conectada con una cantidad significativa de operaciones de E / S necesarias para replicar sesiones.

De hecho, si vamos con sesiones pegajosas, no necesitamos ejecutar JBoss en la configuración "todos", podríamos usar una configuración basada en "predeterminada" o "estándar".

Lo único que se debe hacer es cambiar en $ JBOSS_HOME / server / YOUR_NODE_NAME / deploy / jbossweb.sar / server.xml:

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