Collant Sessions et la Réplication de Session

Je suis d'évaluer le cas de l'utilisation de collants sessions avec la réplication de Session dans tomcat. De mon évaluation initiale, j'ai pensé que si nous permettons à la réplication de Session, puis la séance a commencé dans un tomcat nœud sera transmis à toutes les autres tomcat nœuds et donc nous n'avons pas besoin collant session de continuer les séances et la demande peut être repris par n'importe quel nœud.

Mais il semble que la réplication de session est en général utilisé avec les sessions, sinon l'id de session doit être changé chaque fois que la demande est transmise à un autre noeud. ref: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node

Quelqu'un peut-il expliquer ce qu'est l'utilisation réelle de la réplication de session si vous avez d'activer le collant session? Parce qu'alors, vous être inutilement la copie de la session sur chaque nœud, lorsque la demande avec un id de session est toujours le même nœud. Il pourrait être bénéfique dans le cas d'un nœud en panne, mais cela ne se produit pas fréquemment et à l'aide de la réplication de session uniquement pour ça me paraît exagéré.

  • Pas la réponse à ce que vous avez demandé, mais peut-être encore être utile: vous pouvez vérifier memcached-session-manager (code.google.com/p/memcached-session-manager), qui fournit la réplication de session aussi pour les non-collante sessions.
  • Depuis le nœud auquel l'utilisateur est connecté, ce qui peut aller vers le bas, la réplication de session permet à d'autres nœud sain pour reprendre la même session. Ainsi, au lieu de "quelqu'un Peut-il expliquer ce qu'est l'utilisation réelle de réplication de session si vous avez d'activer le collant session?", Je préfère demander: quelqu'un Peut-il expliquer ce qu'est l'utilisation réelle de collant session si vous avez de réplication de session? parce que c'est plus intéressant... et la seule réponse qui me vient à l'esprit est: collant session dans ce cas seulement accélère la communication, et la session est-il de toute façon avec ou sans elle.
InformationsquelleAutor Ashish | 2011-06-16
  1. 8

    Je pense que le seul réel avantage est d'être en mesure d'arrêter Tomcat cas, sans beaucoup de réflexion. En particulier, cela s'applique aujourd'hui dans les nuages du monde (pensez Amazon AWS instances ponctuelles) lorsque les nœuds pouvez aller sur et hors de vraiment souvent. Alternative serait d'acheter un décent d'équilibrage de la charge qui prend en charge le nœud de drainage. Mais décent équilibreurs de charge sont chers, et le drainage prend du temps.

    Un autre scénario que je peux penser à est de une (mauvaise mise en œuvre de l') panier où les éléments sont conservés dans le HttpSession et d'arrêt de obligerait l'utilisateur à ré-achat (ce qui serait susceptible de mener à une vente perdue).

    Mais dans la plupart des cas, vous êtes de droite avantage d'avoir deux sessions pense-bête et la réplication de session est très négligeable.

    • Merci pour votre réponse. Grâce semble bien, mais encore je ne suis pas sûr si la réplication de session doit être activée avec les sessions ou peut-il être utilisé sans collant des séances de trop?
    • La réplication peut être utilisé sans collant sessions et vice versa.
    • Mais comme indiqué dans ce lien... tomcat.apache.org/tomcat-6.0-doc/... ... il semble que l'activation de la réplication de session sans collant session semble causer des problèmes
    • Je ne vois pas où l'article dit ceci pose des problèmes. L'Article parle de mod_jk qui n'est pas pertinent dans ce contexte.
    InformationsquelleAutor mindas
  2. 69

    Comme Mindas a expliqué à l'avant :

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

    • Si vous utilisez la réplication de session sans collant session : Imaginez que vous avez un seul utilisateur à l'aide de votre application web, et vous avez 3
      tomcat instances. Cet utilisateur envoie plusieurs requêtes à votre application,
      le loadbalancer enverra certains de ces demandes à la première tomcat
      exemple, et de l'envoyer de l'autre de ces demandes à la secondth
      exemple, et d'autres à la troisième.
    • Si vous utilisez collant session sans réplication : Imaginez que vous avez un seul utilisateur à l'aide de votre application web, et vous avez 3 tomcat
      les instances. Cet utilisateur envoie plusieurs requêtes à votre application, puis la
      loadbalancer enverra la première demande de l'utilisateur à l'une des trois
      tomcat cas, et tous les autres demandes qui sont envoyées par cette
      de 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 le serveur tomcat
      instance (instance de tomcat qui est utilisé) le loadbalancer envoie l'
      autres demandes à une autre instance de tomcat qui est encore
      en cours d'exécution, MAIS que vous n'utilisez pas la réplication de session, l'instance
      tomcat qui reçoit les demandes restantes n'ont pas une copie de
      la session de l'utilisateur, ensuite pour ce tomcat à l'utilisateur de commencer une session :
      l'utilisateur lâche 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 collant session AVEC la réplication de session : Imaginez que vous avez un seul utilisateur à l'aide de votre application web, et vous avez 3 tomcat
      les instances. Cet utilisateur envoie plusieurs requêtes à votre application, puis la
      loadbalancer enverra la première demande de l'utilisateur à l'une des trois
      tomcat cas, et tous les autres demandes qui sont envoyées par cette
      de 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 le serveur tomcat
      instance (instance de tomcat qui est utilisé) le loadbalancer envoie l'
      autres demandes à une autre instance de tomcat qui est encore
      en cours d'exécution, tant que vous utilisez la réplication de session, l'instance de tomcat qui
      reçoit les demandes restantes a une copie de la session de l'utilisateur, puis
      l'utilisateur conserve à sa session : l'utilisateur de continuer à parcourir votre site web
      app sans être déconnecté, l'arrêt de l'instance de tomcat
      n'a pas d'incidence sur la navigation de l'utilisateur.
    • C'est bien compris, ma question était seulement si elle a une autre utilisation en dehors de crash du nœud, comme je l'ai mentionné dans la question elle-même ", Il pourrait être bénéfique dans le cas d'un nœud en panne".
    • ok, vous parlez de "nœud de s'écraser", mais vous pourriez aussi vous voulez changer les deux nœuds, ou de supprimer des deux nœuds, ou vous souhaitez mettre à jour votre application web... et en faisant cela, vous ne voulez pas arrêter la session des utilisateurs, vous ne voulez pas voir votre intervention. Ensuite, à l'aide de la réplication, pour vous permettre de le faire.
    • Ainsi, en cas d'lorsque nous avons la réplication de session, collant session seulement accélère la communication, parce que la session existe de toute façon avec ou sans elle. Suis-je le droit?
    InformationsquelleAutor Nico
  3. 0

    Juste pour clarifier les problèmes de configuration de JBoss 5.X dans "tous" configuration de base avec mod_jk. Réglage collant séances chez les travailleurs.fichier de propriétés

     worker.list=loadbalancer

 ... nodes configuration omitted

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

    ne pas empêcher la réplication de session. Pour désactiver la réplication de session sur JBoss nous avons besoin de mettre dans $JBOSS_HOME\server\YOUR_NODE_NAME\deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-manager-jboss-beans.xml cacheMode paramètre LOCAL.

    Généralement en collant session scénario nous ne voulons pas de réplication de session, puisque nous ne voulons pas de traitement supplémentaire connecté avec quantité importante d'opérations d'e/S nécessaire pour reproduire les séances.

    En fait, si aller avec collant séances, nous n'avons pas besoin de courir JBoss dans le "tout" de la configuration, on peut utiliser "par défaut" ou "standard" en fonction de la configuration.

    La seule chose qui doit être fait est de changer dans $JBOSS_HOME/server/YOUR_NODE_NAME/deploy/jbossweb.sar/server.xml:

    <Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">
    • Devraient-ils être worker.loadbalancer.sticky_session=false dans votre exemple?
    InformationsquelleAutor Piotr Kochański