Hi,
I have changed flag sticky_session in my workers.properties file:
worker.lb_worker.sticky_session=0
But system is experiencing the same behaviour:
FINE: Cluster is standalone: reset Session Request Delta at context /SUE
09/08/2010 12:20:24 org.apache.catalina.ha.session.JvmRouteBinderValve
getManager
FINE: Found Cluster DeltaManager
org.apache.catalina.ha.session.deltamana...@4c262a90 at /SUE
09/08/2010 12:20:24 org.apache.catalina.ha.session.JvmRouteBinderValve
handleJvmRoute
FINE: Detected a failover with different jvmRoute - orginal route: [workerW37]
new one: [workerW38] at session id [65A210E6ABE6347B6B3AC89F31729836.workerW37]
09/08/2010 12:20:24 org.apache.catalina.ha.session.JvmRouteBinderValve
getManager
FINE: Found Cluster DeltaManager
org.apache.catalina.ha.session.deltamana...@4c262a90 at /SUE
09/08/2010 12:20:24 org.apache.catalina.ha.session.JvmRouteBinderValve
changeRequestSessionID
FINE: Set Orginal Session id at request attriute
org.apache.catalina.ha.session.JvmRouteOrignalSessionID value:
65A210E6ABE6347B6B3AC89F31729836.workerW37
09/08/2010 12:20:24 org.apache.catalina.ha.tcp.SimpleTcpCluster send
FINE: No members in cluster, ignoring
message:SESSIONID-UPDATE#localhost./SUE#65A210E6ABE6347B6B3AC89F31729836.workerW37:65A210E6ABE6347B6B3AC89F31729836.workerW38
09/08/2010 12:20:24 org.apache.catalina.ha.session.JvmRouteBinderValve
changeSessionID
FINE: Changed session from [65A210E6ABE6347B6B3AC89F31729836.workerW37] to
[65A210E6ABE6347B6B3AC89F31729836.workerW38]
09/08/2010 12:20:24 org.apache.catalina.ha.session.JvmRouteBinderValve
handlePossibleTurnover
Look at:
FINE: Changed session from [65A210E6ABE6347B6B3AC89F31729836.workerW37] to
[65A210E6ABE6347B6B3AC89F31729836.workerW38]
1. Don't code your application assuming the session ID is constant
--> We will try if is there no other option.
2.- Don't use sticky session.
--> I have tried to add the sticky_sessions=0 but I got the same behaviour.
I have the following lines in server.xml file:
<Valve
className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<ClusterListener
className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener
className="org.apache.catalina.ha.session.ClusterSessionListener"/>
To disable sticky sessions sould I comment the second line ?
3. Add a listener to handle the change in session ID
--> Yes, but there is no method related to session renaming. When a session is
renamed a sessionCreation event is rised (no rename (because does not exist)
and no descruction method)
Thanks in advance.
Oscar Segarra Rey
Àrea de tecnologies de la informació i les comunicacions
Departament de la Presidència
C/ Sant Honorat 1-3 - 08002 Barcelona
934024834
-----Mensaje original-----
De: Mark Thomas [mailto:[email protected]]
Enviado el: dissabte, 31 / juliol / 2010 15:07
Para: Tomcat Users List
Asunto: Re: Session ID changes when a node goes down
On 31/07/2010 13:58, Oscar Segarra Rey wrote:
> Hi,
>
> We are developing a web application wich uses session listeners and such kind
> of stuff in order to control which users are loged in every time.
>
> Nevertheless we have experienced a developement problem due to the session ID
> changes when one node goes down.
>
> 30/07/2010 13:08:27 org.apache.catalina.ha.session.JvmRouteBinderValve
> changeSessionID
> FINE: Changed session from [18434EBFCF3D1009BBEEE5C02D370BCF.workerW37] to
> [18434EBFCF3D1009BBEEE5C02D370BCF.workerW38]
The jvmRoute part of the session ID is required for sticky sessions to
work. If a node goes down, the session fails over to another node and
hence the jvmRoute has to change.
> I think session ID should not change its ID or should be a way to avoid this
> rename processs.
>
> Is there any workarround or change this behaviour ?
1. Don't code your application assuming the session ID is constant
2. Don't use sticky sessions
3. Add a listener to handle the change in session ID
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
