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:mcmor...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
