You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Roy McMorran <mc...@mdibl.org> on 2009/04/02 16:59:23 UTC
Session Replication in Cluster
Hello all,
I've built a very simple 2-member Tomcat cluster for testing, but I am
unable to get the session replication quite right. The problem is when
I fail one member of the cluster. The behavior I was expecting is that
the other cluster member would take over the session ids for the failed
member. However it is appending it's own jvmRoute value to the session
id, and thus setting a new cookie.
Details:
I have 2 cluster members, "itchy" and "scratchy", running on the same
physical server, and CATALINA_BASE is /var/tomcat/itchy and
/var/tomcat/scratchy respectively. Tomcat 6.0.18 binaries, etc. are at
/usr/local/tomcat. Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is also
on the same server). I am using sticky sessions.
Here are the access logs for the 2 members from a short "failover"
experiment (note I'm including the session ID in the 2nd field). The
session starts on scratchy. From scratchy_access_log.2009-04-02.txt:
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
[02/Apr/2009:10:19:55 -0400] "GET / HTTP/1.1" 200 14612
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
[02/Apr/2009:10:20:14 -0400] "GET /about/ HTTP/1.1" 200 19507
At 10:21:39 AM I do a kill -9 on the scratchy instance. Now the traffic
goes to the other cluster member as expected. From
itchy_access_log.2009-04-02.txt:
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
[02/Apr/2009:10:22:11 -0400] "GET /about/publications/ HTTP/1.1" 200 18263
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
[02/Apr/2009:10:22:32 -0400] "GET /about/changes/ HTTP/1.1" 200 12736
Note however that the new member's jvmRoute value is now appended to the
session id. I thought is was supposed to stay exactly the same after
failover.
Additional details can be found as follows:
server.xml for "itchy" - see:
http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt
server.xml for "scratchy" - see:
http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt
context.xml (identical) - see:
https://gillnet.mdibl.org/~mcmorran/context.xml.txt
workers.properties:
https://gillnet.mdibl.org/~mcmorran/workers.properties
I've also included the catalina.out file for both, from startup and
through the test at:
https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out
https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out
I'd appreciate any advice on where I went wrong. Thanks and best wishes,
Roy
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Roy McMorran <mc...@mdibl.org>.
Mark Thomas wrote:
> Roy McMorran wrote:
>
>> Thanks Mark,
>>
>> Is it the expected behavior then, that the 2nd part of the session ID
>> changes after a failover, and a new cookie is set?
>>
>
> Yes
>
> Mark
>
Interesting. I am certain I saw the other behavior (both parts of the
session ID were preserved) earlier in my testing, but I haven't been
able to reproduce it since...now I know why. Thanks for your help Mark
and Jorge.
Cheers,
Roy
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Mark Thomas <ma...@apache.org>.
Roy McMorran wrote:
> János Löbb wrote:
>>
>> If You look the >>values<< created by the session earlier with
>> ...node1, than You will see the same values after fail over with
>> ...node2. A new session would not know about them.
>>
>> To verify it You can use the supplied SessionExmaple webapp.
>
> OK, trying that.
>
> So, using an example webapp (see:
> https://gillnet.mdibl.org/~mcmorran/session.jsp.txt
>
> (which just uses session.getID() )
>
> ...should it return *just* the session ID part, or the concatenation of
> the session ID and the jvmRoute?
>
> Here's what I see:
>
> Before failover:
> This is the session id FEBA6A8127A69079C79B7A641158CE20.itchy
> This is an existing session
>
> After failover:
> This is the session id FEBA6A8127A69079C79B7A641158CE20.scratchy
> This is an existing session
Which is 100% correct and expected behaviour. The session ID *has* to
change as the last part, the route, is used by the load balancer to
maintain session stickiness. The contents of both of those sessions will
be identical.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by János Löbb <ja...@yale.edu>.
To stick with the analogy:
Your session's baby part is: FEBA6A8127A69079C79B7A641158CE20 and
that remains the same if with daddy or mommy.
Your session's daddy part is: itchy
and
Your session's mommy part is: scratchy
Enjoy them :)
János
On Apr 3, 2009, at 5:32 PM, Roy McMorran wrote:
> János Löbb wrote:
>>
>> If You look the >>values<< created by the session earlier
>> with ...node1, than You will see the same values after fail over
>> with ...node2. A new session would not know about them.
>>
>> To verify it You can use the supplied SessionExmaple webapp.
>
> OK, trying that.
>
> So, using an example webapp (see:
> https://gillnet.mdibl.org/~mcmorran/session.jsp.txt
>
> (which just uses session.getID() )
>
> ...should it return *just* the session ID part, or the concatenation
> of the session ID and the jvmRoute?
>
> Here's what I see:
>
> Before failover:
> This is the session id FEBA6A8127A69079C79B7A641158CE20.itchy
> This is an existing session
>
> After failover:
> This is the session id FEBA6A8127A69079C79B7A641158CE20.scratchy
> This is an existing session
>
> Thanks,
> -r
>
> --
> Roy McMorran
> Systems Administrator
> MDI Biological Laboratory
> mcmorran@mdibl.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Roy McMorran <mc...@mdibl.org>.
János Löbb wrote:
>
> If You look the >>values<< created by the session earlier with
> ...node1, than You will see the same values after fail over with
> ...node2. A new session would not know about them.
>
> To verify it You can use the supplied SessionExmaple webapp.
OK, trying that.
So, using an example webapp (see:
https://gillnet.mdibl.org/~mcmorran/session.jsp.txt
(which just uses session.getID() )
...should it return *just* the session ID part, or the concatenation of
the session ID and the jvmRoute?
Here's what I see:
Before failover:
This is the session id FEBA6A8127A69079C79B7A641158CE20.itchy
This is an existing session
After failover:
This is the session id FEBA6A8127A69079C79B7A641158CE20.scratchy
This is an existing session
Thanks,
-r
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Roy McMorran <mc...@mdibl.org>.
János Löbb wrote:
>
> If You look the >>values<< created by the session earlier with
> ...node1, than You will see the same values after fail over with
> ...node2. A new session would not know about them.
>
> To verify it You can use the supplied SessionExmaple webapp.
>
> It is like passing a baby among family members and making a snapshot.
> As long as the baby the same everything is alright :)
>
Thank you János, that is a great analogy! Appreciate your reply.
Cheers,
-r
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by János Löbb <ja...@yale.edu>.
On Apr 3, 2009, at 3:31 PM, Roy McMorran wrote:
> Mark Thomas wrote:
>> Roy McMorran wrote:
>>
>>> Is it the expected behavior then, that the 2nd part of the session
>>> ID
>>> changes after a failover, and a new cookie is set?
>>>
>>
>> Yes
>>
>>
>
> OK, please bear with me here, I may be just showing my ignorance
> with respect to Tomcat and web applications in general, but...
>
> If the session ID changes from "ABC123.node1" to "ABC123.node2",
> then you will start a new session at the browser.
> If you are going to establish a new session anyway, why bother
> replicating the first part of the session ID at all?
>
> Thanks,
> -r
>
> --
> Roy McMorran
> Systems Administrator
> MDI Biological Laboratory
> mcmorran@mdibl.org
>
If You look the >>values<< created by the session earlier
with ...node1, than You will see the same values after fail over
with ...node2. A new session would not know about them.
To verify it You can use the supplied SessionExmaple webapp.
It is like passing a baby among family members and making a snapshot.
As long as the baby the same everything is alright :)
János
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Roy McMorran <mc...@mdibl.org>.
Caldarale, Charles R wrote:
>> From: Roy McMorran [mailto:mcmorran@mdibl.org]
>> Subject: Re: Session Replication in Cluster
>>
>> If the session ID changes from "ABC123.node1" to "ABC123.node2", then
>> you will start a new session at the browser.
>>
>
> No, you get a new *cookie* at the browser; the session is something only the server has cognizance of. Assuming your session replication across nodes is working properly, the user sitting at the browser won't know that anything has changed.
>
>
Thanks Chuck, that was helpful. I think I was being misled by the
behavior of the application I'm trying to cluster. It looked like a
whole new session had been established after the failover, but upon
closer investigation I can see now that is not the case.
Best wishes,
-r
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Session Replication in Cluster
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Roy McMorran [mailto:mcmorran@mdibl.org]
> Subject: Re: Session Replication in Cluster
>
> If the session ID changes from "ABC123.node1" to "ABC123.node2", then
> you will start a new session at the browser.
No, you get a new *cookie* at the browser; the session is something only the server has cognizance of. Assuming your session replication across nodes is working properly, the user sitting at the browser won't know that anything has changed.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Roy McMorran <mc...@mdibl.org>.
Mark Thomas wrote:
> Roy McMorran wrote:
>
>> Is it the expected behavior then, that the 2nd part of the session ID
>> changes after a failover, and a new cookie is set?
>>
>
> Yes
>
>
OK, please bear with me here, I may be just showing my ignorance with
respect to Tomcat and web applications in general, but...
If the session ID changes from "ABC123.node1" to "ABC123.node2", then
you will start a new session at the browser.
If you are going to establish a new session anyway, why bother
replicating the first part of the session ID at all?
Thanks,
-r
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Mark Thomas <ma...@apache.org>.
Roy McMorran wrote:
> Mark Thomas wrote:
>>
>> Nope. The job of that valve is to change the route - exactly what you
>> are seeing.
>>
>>
> Thanks Mark,
>
> Is it the expected behavior then, that the 2nd part of the session ID
> changes after a failover, and a new cookie is set?
Yes
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Roy McMorran <mc...@mdibl.org>.
Mark Thomas wrote:
>
> Nope. The job of that valve is to change the route - exactly what you
> are seeing.
>
>
Thanks Mark,
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Thanks,
Roy
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Mark Thomas <ma...@apache.org>.
Roy McMorran wrote:
> Hi Jorge, thanks for the reply.
>
> Actually no, these are the access logs from the Tomcat cluster members;
> you can view the corresponding AccessLogValve entries in the server.xml
> files referenced below.
>
> I included those logs for illustration, but I have confirmed that those
> are the actual session IDs at the browser. After the failover the new
> Tomcat cluster member sends a new Set-Cookie header with the new session
> ID.
>
> You're right that the first portion of the session ID does seem to be
> replicated properly, but I thought it was the function of
> JvmRouteBinderValve to update the entire session ID in a failover,
> including the jvmRoute portion.
Nope. The job of that valve is to change the route - exactly what you
are seeing.
Mark
>
> Best wishes,
> Roy
>
> Jorge Medina wrote:
>> Are your logs Apache logs? Mod_jk logs?
>>
>> If it is Apache, the question would probably better answer in the Apache
>> mailing list. Anyway, What does your LogFormat string looks like?
>> I bet what you see in the logs is the concatenation of the session ID
>> and the worker name. I doubt two servers would generate the same hex
>> digits for the session. Therefore, your server must be working as
>> expected, you are just interpreting the logs incorrectly.
>>
>> -----Original Message-----
>> From: Roy McMorran [mailto:mcmorran@mdibl.org] Sent: Thursday, April
>> 02, 2009 10:59 AM
>> To: Tomcat Users List
>> Subject: Session Replication in Cluster
>>
>> Hello all,
>>
>>
>> I've built a very simple 2-member Tomcat cluster for testing, but I am
>> unable to get the session replication quite right. The problem is when
>> I fail one member of the cluster. The behavior I was expecting is that
>> the other cluster member would take over the session ids for the failed
>> member. However it is appending it's own jvmRoute value to the session
>> id, and thus setting a new cookie.
>>
>>
>> Details:
>> I have 2 cluster members, "itchy" and "scratchy", running on the same
>> physical server, and CATALINA_BASE is /var/tomcat/itchy and
>> /var/tomcat/scratchy respectively. Tomcat 6.0.18 binaries, etc. are at
>> /usr/local/tomcat. Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is also
>> on the same server). I am using sticky sessions.
>>
>>
>> Here are the access logs for the 2 members from a short "failover"
>> experiment (note I'm including the session ID in the 2nd field). The
>> session starts on scratchy. From scratchy_access_log.2009-04-02.txt:
>>
>> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
>> [02/Apr/2009:10:19:55 -0400] "GET / HTTP/1.1" 200 14612
>> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
>> [02/Apr/2009:10:20:14 -0400] "GET /about/ HTTP/1.1" 200 19507
>>
>>
>> At 10:21:39 AM I do a kill -9 on the scratchy instance. Now the traffic
>> goes to the other cluster member as expected. From
>> itchy_access_log.2009-04-02.txt:
>>
>> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
>> [02/Apr/2009:10:22:11 -0400] "GET /about/publications/ HTTP/1.1" 200
>> 18263
>> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
>> [02/Apr/2009:10:22:32 -0400] "GET /about/changes/ HTTP/1.1" 200 12736
>>
>>
>> Note however that the new member's jvmRoute value is now appended to the
>> session id. I thought is was supposed to stay exactly the same after
>> failover.
>>
>>
>> Additional details can be found as follows:
>>
>> server.xml for "itchy" - see:
>> http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt
>>
>> server.xml for "scratchy" - see:
>> http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt
>>
>> context.xml (identical) - see:
>> https://gillnet.mdibl.org/~mcmorran/context.xml.txt
>>
>> workers.properties:
>> https://gillnet.mdibl.org/~mcmorran/workers.properties
>>
>> I've also included the catalina.out file for both, from startup and
>> through the test at:
>> https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out
>> https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out
>>
>>
>> I'd appreciate any advice on where I went wrong. Thanks and best
>> wishes,
>> Roy
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Roy McMorran <mc...@mdibl.org>.
Hi Jorge, thanks for the reply.
Actually no, these are the access logs from the Tomcat cluster members;
you can view the corresponding AccessLogValve entries in the server.xml
files referenced below.
I included those logs for illustration, but I have confirmed that those
are the actual session IDs at the browser. After the failover the new
Tomcat cluster member sends a new Set-Cookie header with the new session ID.
You're right that the first portion of the session ID does seem to be
replicated properly, but I thought it was the function of
JvmRouteBinderValve to update the entire session ID in a failover,
including the jvmRoute portion.
Best wishes,
Roy
Jorge Medina wrote:
> Are your logs Apache logs? Mod_jk logs?
>
> If it is Apache, the question would probably better answer in the Apache
> mailing list.
> Anyway, What does your LogFormat string looks like?
>
> I bet what you see in the logs is the concatenation of the session ID
> and the worker name. I doubt two servers would generate the same hex
> digits for the session. Therefore, your server must be working as
> expected, you are just interpreting the logs incorrectly.
>
> -----Original Message-----
> From: Roy McMorran [mailto:mcmorran@mdibl.org]
> Sent: Thursday, April 02, 2009 10:59 AM
> To: Tomcat Users List
> Subject: Session Replication in Cluster
>
> Hello all,
>
>
> I've built a very simple 2-member Tomcat cluster for testing, but I am
> unable to get the session replication quite right. The problem is when
> I fail one member of the cluster. The behavior I was expecting is that
> the other cluster member would take over the session ids for the failed
> member. However it is appending it's own jvmRoute value to the session
> id, and thus setting a new cookie.
>
>
> Details:
> I have 2 cluster members, "itchy" and "scratchy", running on the same
> physical server, and CATALINA_BASE is /var/tomcat/itchy and
> /var/tomcat/scratchy respectively. Tomcat 6.0.18 binaries, etc. are at
> /usr/local/tomcat. Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is also
> on the same server). I am using sticky sessions.
>
>
> Here are the access logs for the 2 members from a short "failover"
> experiment (note I'm including the session ID in the 2nd field). The
> session starts on scratchy. From scratchy_access_log.2009-04-02.txt:
>
> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
> [02/Apr/2009:10:19:55 -0400] "GET / HTTP/1.1" 200 14612
> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
> [02/Apr/2009:10:20:14 -0400] "GET /about/ HTTP/1.1" 200 19507
>
>
> At 10:21:39 AM I do a kill -9 on the scratchy instance. Now the traffic
> goes to the other cluster member as expected. From
> itchy_access_log.2009-04-02.txt:
>
> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
> [02/Apr/2009:10:22:11 -0400] "GET /about/publications/ HTTP/1.1" 200
> 18263
> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
> [02/Apr/2009:10:22:32 -0400] "GET /about/changes/ HTTP/1.1" 200 12736
>
>
> Note however that the new member's jvmRoute value is now appended to the
> session id. I thought is was supposed to stay exactly the same after
> failover.
>
>
> Additional details can be found as follows:
>
> server.xml for "itchy" - see:
> http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt
>
> server.xml for "scratchy" - see:
> http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt
>
> context.xml (identical) - see:
> https://gillnet.mdibl.org/~mcmorran/context.xml.txt
>
> workers.properties:
> https://gillnet.mdibl.org/~mcmorran/workers.properties
>
> I've also included the catalina.out file for both, from startup and
> through the test at:
> https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out
> https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out
>
>
> I'd appreciate any advice on where I went wrong. Thanks and best
> wishes,
> Roy
>
>
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Session Replication in Cluster
Posted by Jorge Medina <jm...@e-dialog.com>.
Are your logs Apache logs? Mod_jk logs?
If it is Apache, the question would probably better answer in the Apache
mailing list.
Anyway, What does your LogFormat string looks like?
I bet what you see in the logs is the concatenation of the session ID
and the worker name. I doubt two servers would generate the same hex
digits for the session. Therefore, your server must be working as
expected, you are just interpreting the logs incorrectly.
-----Original Message-----
From: Roy McMorran [mailto:mcmorran@mdibl.org]
Sent: Thursday, April 02, 2009 10:59 AM
To: Tomcat Users List
Subject: Session Replication in Cluster
Hello all,
I've built a very simple 2-member Tomcat cluster for testing, but I am
unable to get the session replication quite right. The problem is when
I fail one member of the cluster. The behavior I was expecting is that
the other cluster member would take over the session ids for the failed
member. However it is appending it's own jvmRoute value to the session
id, and thus setting a new cookie.
Details:
I have 2 cluster members, "itchy" and "scratchy", running on the same
physical server, and CATALINA_BASE is /var/tomcat/itchy and
/var/tomcat/scratchy respectively. Tomcat 6.0.18 binaries, etc. are at
/usr/local/tomcat. Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is also
on the same server). I am using sticky sessions.
Here are the access logs for the 2 members from a short "failover"
experiment (note I'm including the session ID in the 2nd field). The
session starts on scratchy. From scratchy_access_log.2009-04-02.txt:
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
[02/Apr/2009:10:19:55 -0400] "GET / HTTP/1.1" 200 14612
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
[02/Apr/2009:10:20:14 -0400] "GET /about/ HTTP/1.1" 200 19507
At 10:21:39 AM I do a kill -9 on the scratchy instance. Now the traffic
goes to the other cluster member as expected. From
itchy_access_log.2009-04-02.txt:
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
[02/Apr/2009:10:22:11 -0400] "GET /about/publications/ HTTP/1.1" 200
18263
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
[02/Apr/2009:10:22:32 -0400] "GET /about/changes/ HTTP/1.1" 200 12736
Note however that the new member's jvmRoute value is now appended to the
session id. I thought is was supposed to stay exactly the same after
failover.
Additional details can be found as follows:
server.xml for "itchy" - see:
http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt
server.xml for "scratchy" - see:
http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt
context.xml (identical) - see:
https://gillnet.mdibl.org/~mcmorran/context.xml.txt
workers.properties:
https://gillnet.mdibl.org/~mcmorran/workers.properties
I've also included the catalina.out file for both, from startup and
through the test at:
https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out
https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out
I'd appreciate any advice on where I went wrong. Thanks and best
wishes,
Roy
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Replication in Cluster
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
what you're seeing is correct.
the server did fail over, and by changing the session id, it ensures
that it does not do "fail back"
Filip
Roy McMorran wrote:
> Hello all,
>
>
> I've built a very simple 2-member Tomcat cluster for testing, but I am
> unable to get the session replication quite right. The problem is
> when I fail one member of the cluster. The behavior I was expecting
> is that the other cluster member would take over the session ids for
> the failed member. However it is appending it's own jvmRoute value to
> the session id, and thus setting a new cookie.
>
>
> Details:
> I have 2 cluster members, "itchy" and "scratchy", running on the same
> physical server, and CATALINA_BASE is /var/tomcat/itchy and
> /var/tomcat/scratchy respectively. Tomcat 6.0.18 binaries, etc. are
> at /usr/local/tomcat. Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is
> also on the same server). I am using sticky sessions.
>
>
> Here are the access logs for the 2 members from a short "failover"
> experiment (note I'm including the session ID in the 2nd field). The
> session starts on scratchy. From scratchy_access_log.2009-04-02.txt:
>
> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
> [02/Apr/2009:10:19:55 -0400] "GET / HTTP/1.1" 200 14612
> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
> [02/Apr/2009:10:20:14 -0400] "GET /about/ HTTP/1.1" 200 19507
>
>
> At 10:21:39 AM I do a kill -9 on the scratchy instance. Now the
> traffic goes to the other cluster member as expected. From
> itchy_access_log.2009-04-02.txt:
>
> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
> [02/Apr/2009:10:22:11 -0400] "GET /about/publications/ HTTP/1.1" 200
> 18263
> 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
> [02/Apr/2009:10:22:32 -0400] "GET /about/changes/ HTTP/1.1" 200 12736
>
>
> Note however that the new member's jvmRoute value is now appended to
> the session id. I thought is was supposed to stay exactly the same
> after failover.
>
>
> Additional details can be found as follows:
>
> server.xml for "itchy" - see:
> http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt
>
> server.xml for "scratchy" - see:
> http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt
>
> context.xml (identical) - see:
> https://gillnet.mdibl.org/~mcmorran/context.xml.txt
>
> workers.properties:
> https://gillnet.mdibl.org/~mcmorran/workers.properties
>
> I've also included the catalina.out file for both, from startup and
> through the test at:
> https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out
> https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out
>
>
> I'd appreciate any advice on where I went wrong. Thanks and best wishes,
> Roy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org