tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From János Löbb <janos.l...@yale.edu>
Subject Re: [cluster] standalone tomcat hijacks cluster session
Date Fri, 15 Apr 2011 21:41:41 GMT
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-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


Mime
View raw message