Utilisation de tomcat en mode round robin

Question

Je souhaite exécuter mes instances tomcat dans une configuration où les requêtes sont servies à plusieurs instances tomcat via round robin. Je ne veux utiliser aucun gestionnaire de cluster interne. Dans la mesure où je vois si chaque requête est servie par différents tomcats, un identificateur sessionId inconnu arriverait à un tomcat, il serait donc obligé de créer une nouvelle session et d'écraser l'ancien sessionId. Donc, pour chaque demande, une nouvelle session serait créée. Cela semble être beaucoup de frais généraux.

Mon point de vue est-il correct? Y at-il un moyen de désactiver la gestion des sessions Tomcats?

Cordialement, Michael

Answer 1

Une session ne sera créé une fois votre code demande la session, donc si votre application ne nécessite pas la session alors ne tout simplement y accéder. Checkout la section sur getSession() dans HttpServletRequest

http://download.oracle.com/javaee/5/api/javax/servlet/http/HttpServletRequest.html#getSession(boolean)

Je ne sais pas s'il y a un moyen de reproduire la session dans les différentes instances de tomcat si vous avez besoin d'un état utilisateur sans session, vous pouvez utiliser cookies à la place.

EDIT: Si vous avez besoin de répliquer la session, vous pouvez probablement commencer par lire ce document tomcat. http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html

Answer 2

Nous utilisions généralement Tomcat derrière un serveur Web Apache avec mod_jk pour équilibrer la charge des demandes entre les instances Tomcat.

Avec sticky sessions un utilisateur ne recevra une session qu'à la première demande et sera ensuite toujours dirigé vers le Tomcat d'où provient sa session. Il n'est donc pas nécessaire de répliquer les sessions sur tous les Tomcats et les requêtes seront également réparties sur les Tomcats.

Bien sûr, cela n'assure pas une sorte de round-robin que vous avez demandé.

Answer 3

Fondamentalement, vous avez deux choix:

1) recréent vos sessions afin qu'ils deviennent accessibles par un nœud Tomcat. Solutions: Tomcat Cluster, memcached-session-manager, éventuellement d'autres.

2) Utilisez un équilibreur de charge et installez des sessions persistantes. Les premières demandes seront routées de manière aléatoire sur une base circulaire, mais les demandes suivantes resteront sur le même serveur. Solutions: mod_proxy, gestionnaires de trafic matériel.

L'inconvénient de la première option est que la réplication de session est coûteuse, pas très fiable et nécessite souvent des données Serializable à mettre en session. L'inconvénient de la deuxième approche est que si vous arrêtez votre Tomcat pour la maintenance, les utilisateurs seront obligés de se reconnecter.

Vous supposez à tort que "pour chaque requête, une nouvelle session sera créée". La nouvelle session sera créée uniquement si elle n'a pas été créée auparavant sur ce même serveur ou si elle a été créée mais a déjà expiré.