Hi Michael, Thanks for the reply. I followed the technique you suggested, but I could not make my app running. From first cluster member it is happily going to second cluster member, but from there it is not moving (If there are no connection there also). Besides invalidating the HttpSession, I erased the cookie with name "sid". I tried to erase cookie with name jsessionid also, but seems that it does not exists. Not only ";jsessionid=.TomcatA" but I tried by appending "a=b&jsessionid=.TomcatA" also. Still no luck. Between, which session provides the sticky behavior and where it is stored. And, does the string ";jsessionid=someid.TomcatA" travel with the request?
I appreciate any help in this regard. Regards, Srinivas -----Original Message----- From: Michael Echerer [mailto:[EMAIL PROTECTED] Sent: Sunday, January 16, 2005 4:55 PM To: Tomcat Users List Subject: Re: Session is too sticky Hi! What you could do is to give Apache a hint where to direct a request to. E.g. you could not simply invalidate the session, but also redirect to your start page again with a little "trick". Add a ;jsessionid= string to the URL. Assume your Tomcat JVM routes are called e.g. tomcatA, tomcatB, tomcatC, etc. you will have noticed that the ;jsessionid look like http://someurl;jsessionid=someid.tomcatA or http://someurl;jsessionid=someid.tomcatB etc. It get's interesting when you pass an URL like: http://someurl;jsessionid=.tomcatC Obviously because of the missing sessionid "someid" this can not be or create a valid session on one of your Tomcats, but for your Apache this "flag" is "sticky" enough to direct to that specific Tomcat "tomcatC" (which should be an instance that has enough connections left. In case you don't know which of your Tomcats has connection left, you might randomly add .jsessionid=.tomcat? and redirect until you found a Tomcat you can use. Thus by simple adding an incomplete ;jessionid=.<jvmRoute> you can force Apache to direct to that instance, Tomcat will detect the broken session, create a new one (but since you're already on the correct Tomcat, that's fine). Note: In case one Tomcat is down, Apache will know this in advance and eventhough you specify ;jessionid=.tomcatB you will go to tomcatA or tomcatC, if tomcatB was down. So now problems with failover. I use this mechanism/trick to have an enhanced Tomcat manager application. One frame with all my Tomcat instances that are linked with this ;sessionid=.<jvmRoute> and one frame with the manager html page itself. With some more "magic" I can now deliberately switch between my instances and deploy/start on the instance I want, although Apache would otherwise pop up any manager app due to loadbalancing. 2xApache 2.x, 4xTomcat 5.x, modjk2 Hope that helps! Cheers, Michael Srinivas Rao Ch wrote: > Hi, > > > > I am implementing clustering with Apache + Tomcat + mod_jk2. And, I > enabled Sticky Session. Sticky behavior is happening as expected. > > > > I have a specific requirement. My DB connections for each cluster member > are limited. Once the cluster member's DB connections are exhausted it > has to redirect the request to other cluster members. I am doing this by > redirecting the request to LB again after invalidating the Http Session > (which is used by apache to provide the sticky behavior). I called > invalidate() on session and I am sure session is invalidated. > > > > Still, the session is going to the same cluster member all the time. I > appreciate if somebody can direct me how to solve this problem. > > > > Regards, > > Srinivas > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
