La replica della sessione può avvenire senza sessione appiccicosa?

Question

Nel contesto di Tomcat, la replica della sessione può avviare senza abilitare la sessione appiccicosa?

Comprendo che lo scopo della sessione appiccicosa è avere i "bastoncini" del client a 1 server durante la sessione. Con la replica della sessione, l'interazione del client con il server viene replicata in tutto il cluster (molti server Web).

Nel caso sopra, la replica della sessione può avvenire? La sessione del client IE viene diffusa sebbene i server Web e ogni interazione con qualsiasi server Web viene replicata, pertanto, consentendo un'interazione senza soluzione di continuità.

Answer 1

Afaik, Tomcat Clustering non supporta sessioni non appiccicose. Da Tomcat Docs:

Assicurati che il tuo carico sia configurato per la modalità di sessione appiccicosa.

Ma c'è una soluzione (ho creato, quindi sai che sono distorto :-)) chiamato MEMCACHED-session-manager (MSM), che supporta anche sessioni non appiccicose. usi MSM memcached (o qualsiasi backend che parla il protocollo MemCached) come back -end per il backup/archiviazione della sessione.

Nelle sessioni in modalità non appiccicosa sono memorizzate solo in memcached e non più in Tomcat, come con le sessioni non appiccicose, il negozio di sessione deve essere esterno (per evitare dati stantii).

Supporta anche il blocco della sessione: con sessioni non appiccicose, richieste parallele possono colpire diversi Tomcats e potrebbero modificare la sessione in parallelo, in modo che alcune delle modifiche alla sessione possano essere sovrascritte da altri. Il blocco della sessione consente la sincronizzazione delle richieste parallele che vanno a diversi Tomcats.

Il Home page MSM Descrive principalmente l'approccio della sessione appiccicosa (come è iniziato solo con questo), per i dettagli sulle sessioni non appiccicose che potresti cercare o chiedere sul Mailing List.

I dettagli ed esempi relativi alla configurazione sono disponibili in MSM Wiki (setupandconfiguration).

Solo per darti un'idea riguardo alla complessità: ciò di cui hai bisogno è uno o più memcached server che eseguono (o s.th. memcached simile) e un contesto tomcat aggiornato.xml come questo:

<Context>
  ...
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:host1.domain.com:11211,n2:host2.domain.com:11211"
    sticky="false"
    sessionBackupAsync="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    />
</Context>

Il bilanciatore del carico non ha bisogno di una configurazione speciale, quindi una volta che hai queste cose in atto puoi iniziare a testare l'applicazione.

Answer 2

Un eccellente articolo su questo argomento qui:

• http://www.mulesoft.com/tomcat-cluster

Il prodotto in terracotta che menzionano ha un tutorial semplicistico qui:

• http://www.terracotta.org/documentation/web-sessions/get-started

Terracotta funziona su Tomcat ma devi prestare attenzione a controllare quali pezzi di terracotta sono gratuiti e quali sono commerciali. Un paio di anni fa il loro negozio ridondante è stato pagato e non ricordo che questa soluzione era un prodotto separato.

Answer 3

In realtà ho trovato l'inverso di questa domanda. La replica della sessione per me (TOMCAT7) con le opzioni OOTB funziona solo correttamente senza sessione appiccicosa. Dopo aver girato l'accesso ho scoperto che con JVMRoutes abilitato il mio ID di sessione va da A123456789 ad A123456789.01 - Suffisso con JVMRoute. Quella sessione viene replicata correttamente dal nodo 01 nel cluster al nodo 02 ma utilizza lo stesso ID (A123456789.01). Quando prendo il nodo 01 dal cluster, il traffico inizia ad attaccarsi al nodo 02 - e ora cerca una sessione A123456789.02 che ovviamente non esiste. .01 è lì, ma sostanzialmente si siede inattivo fino alla scadenza. Se sollevo l'altro server e le sessioni vengono replicate e poi abbasso 02, ottengo un comportamento ancora più strano perché la sessione viene raccolta da dove si era interrotta.

Per me, finora, la replica della sessione senza sessioni appiccicose (solo RR regolare tra i nodi nel cluster) è l'unica cosa che ha funzionato.