Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49D602BE.5020808@apache.org>
Date: Fri, 03 Apr 2009 13:36:14 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Session Replication in Cluster
References: <49D4D2CB.3060103@mdibl.org>
 <9DD36C99332AB7438F8D73C048D8C62C02565B5E@sneezy.ad.e-dialog.com>
 <49D601E6.9020509@mdibl.org>
In-Reply-To: <49D601E6.9020509@mdibl.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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