Hi, Looks like this session hijacking is a jk phenomena.
If I shut down the cluster member tr66 for example and make a standalone tomcat by teking out jvmRoute from the Engine tag and comment out the Cluster tag, and then bring it up then I can get to the SessionExample servlet in two ways. One is to go to it directly via port 8080 like: http://bml0066.yalepath.org:8080/examples/servlets/servlet/SessionExample then after adding some attributes I can see this: Session ID: E118555FBBC8EF040A916C24BFF52C1E Created: Fri Apr 15 16:53:12 EDT 2011 Last Accessed: Fri Apr 15 16:58:18 EDT 2011 The following data is in your session: tc2 = standalone s1 = tc66 standalone s3 = still standalone The other way is to get to the servlet via mod_jk, like: http://bml0066.yalepath.org/examples/servlets/servlet/SessionExample note that I am not using the reverse proxy in this case. Then mod_jk should go to the app in its own session based upon the workers.properties file. But it does not. It hijacks the session in the cluster and I can see this: Session ID: E8714E81BEC77E36D6A9B775A94832DA.tc65 Created: Fri Apr 15 16:47:22 EDT 2011 Last Accessed: Fri Apr 15 16:58:48 EDT 2011 The following data is in your session: s4 = tc65 hijacked tc66 standalone s2 = tc66 down tc65 up s1 = tc66 up tc65 up tc6 = tc65 up tc66 standalone s5 = tc65 hijacked tc66 standalone s6 = tc65 hijacked tc66 standalone s3 = tc65 up tc66 standalone and it surely interfere with the cluster session because when I get to the clustered session I see that the attribute valuse are changed based upon what was change the supposedly "standalone" hijacked session. To get to the clustered session I use the reverse proxy like http://bml0066.yalepath.org/tc/examples/servlets/servlet/SessionExample and I can see there this: Session ID: E8714E81BEC77E36D6A9B775A94832DA.tc65 Created: Fri Apr 15 16:47:22 EDT 2011 Last Accessed: Fri Apr 15 16:59:18 EDT 2011 The following data is in your session: s4 = tc65 hijacked tc66 standalone s2 = tc66 down tc65 up s7 = tc65 up tc66 standalone s1 = tc66 up tc65 up tc6 = tc65 up tc66 standalone s5 = tc65 hijacked tc66 standalone s6 = tc65 hijacked tc66 standalone s3 = tc65 up tc66 standalone all these lines with the word "hijacked" came when I tried to get to the "standalone" session via jk, that is via the URL: http://bml0066.yalepath.org/examples/servlets/servlet/SessionExample So the question is what configuration should I put into workers. properties or to theJkMont in httpd.conf, that when I do not use the reverse proxy and the tomcat is configured as standalone, it will not give me the clustered session from the clustered other tomcat of the other machine, but rather it passes the request to the non-clustered tomcat on machine indicated by the URL ? I see, when the reverse proxy is passing the request to one or the other machine the format of the URL is the same as if I enter it manually on the host of the non-clustered tomcat, so in reality I am not surprised to get the clustered session. What surprises me is that mod_jk is not realizing that some changes were made and the tomcat on the same machine is now not part of the cluster. Or, maybe there is some settings in memory that instructs mod_jk, that ignore the freshly started up standalone tomcat and act like that tomcat is not up yet and go to the tomcat that has the clustered session, and serve that to the user. Thanks ahead, János On Apr 15, 2011, at 1:09 PM, János Löbb wrote: > Hi > > Two machines bml0065 and bml0066. Both have OSX 10.6.6, Tomcat 7.0.10, > mod_jk 1.2.31, and httpd2.2.17. bml0065 is the reverse proxy. > > I am following this test plan with the > examples/servlets/servlet/SessionExample as the webapp. > > <nyissz> > Scenario - tc65, tc66 are running in a cluster. > > 1 Remove tc66 from a cluster while people are using the application. > - Shut down tc66 by logging into the machine as administrator and > issue the sudo /usr/local/tomcat/bin/shutdown.sh commad. > - sudo cp /usr/local/tomcat/conf/no-cluster.xml > /usr/local/conf/server.xml. > - Start up tc66 by issuing: sudo /usr/local/tomcat/bin/startup.sh > > > 2. Access it directly with > http://bml0066.yalepathorg/examples/servlets/servlet/SessionExample. Access > management console and stop/remove the application. Deploy a new version of > the application. > > > 3. Ask users to use an alternative link to that App. > - http://host/app > > > 4. Let it run for some time. > > > 5. Add this new application to the cluster in such a way that the new > application is now deployed > - Shut down tc66: sudo /usr/local/tomcat/bin/shutdown.sh > - sudo cp /usr/local/tomcat/conf/cluster.xml > /usr/local/conf/server.xml. > - Start up tomcat by issuing: sudo > /usr/local/tomcat/bin/startup.sh > > > 6. Take other tomcat tc65 out of the cluster. > - Shut down tc65 by logging into the machine as administrator and > issue the sudo /usr/local/tomcat/bin/shutdown.sh commad. > - copy the /usr/local/tomcat/conf/no-cluster.xml to > /usr/local/conf/server.xml. > - Start up tomcat by issuing: sudo > /usr/local/tomcat/bin/startup.sh > > > 7. Deploy the new app on it while users seamlessly switch to tc66 > > > 8. Add tc65 back to the cluster. > - Shut down tomcat: sudo /usr/local/tomcat/bin/shutdown.sh > - sudo cp /usr/local/tomcat/conf/cluster.xml > /usr/local/conf/server.xml. > - Start up tomcat by issuing: sudo > /usr/local/tomcat/bin/startup.sh > > > 9. Now all apps are in sync on both tomcat instance. > <nyassz> > > It works fine untill step 6. When I bring back tc65 as a standalone tomcat > with no jvmRoute in its engine block and the Cluster tag is commented out, > then when I try to access it via the URL: > http://bml0065.yalepath.org/examples/servlets/servlet/SessionExample > > it hijacks the clustered session. Here is what is on the screen after adding > two new session attribute with its value: > > <nyissz> > Sessions Example > > Session ID: 480C796251BF44355C44FDB0EF4B5AFD.tc66 > Created: Fri Apr 15 12:20:40 EDT 2011 > Last Accessed: Fri Apr 15 12:44:04 EDT 2011 > The following data is in your session: > s4 = tc65 up tc66 still standalone > s2 = still standalone > s9 = tc65 standalone tc66 up > s8 = tc65 down, tc66 up > s1 = standalone > s7 = tc65 down, tc66 up > s5 = tc65 up tc66 down > s6 = both are up > s3 = tc65 up tc66 no cluster > <nyassz> > > It should have come up without the .tc66 affix and with a different sessionid > and should have just he > s2 = still standalone > s1 = standalone > attribute names and values. I did not have this issue when tc66 was in its > standalone mode. > > Compared it with the real clustered session accessed via the URL: > http://bml0065.yalepath.org/tc/examples/servlets/servlet/SessionExample > > <nyissz> > Session ID: 480C796251BF44355C44FDB0EF4B5AFD.tc66 > Created: Fri Apr 15 12:20:40 EDT 2011 > Last Accessed: Fri Apr 15 12:42:30 EDT 2011 > The following data is in your session: > s4 = tc65 up tc66 still standalone > s2 = tc65 up tc66 down > s9 = tc65 standalone tc66 up > s8 = tc65 down, tc66 up > s1 = standalone > s7 = tc65 down, tc66 up > s5 = tc65 up tc66 down > s6 = both are up > s3 = tc65 up tc66 no cluster > <nyassz> > > Here is the reverse proxy config: > ProxyRequests Off > <Proxy balancer://pathCluster> > BalancerMember http://bml0065.yalepath.org loadfactor=10 > BalancerMember http://bml0066.yalepath.org loadfactor=10 > ProxySet lbmethod=bytraffic > </Proxy> > ProxyPass /tc/ balancer://pathCluster/ > ProxyPassReverse /tc/ balancer://pathCluster/ > ProxyPassReverseCookiePAth / / > ProxyPassReverseCookieDomain / / > > > Thanks ahead, > > János > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
