tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Srinivas Rao Ch" <>
Subject RE: Session is too sticky
Date Tue, 18 Jan 2005 16:08:34 GMT
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.


-----Original Message-----
From: Michael Echerer [] 
Sent: Sunday, January 16, 2005 4:55 PM
To: Tomcat Users List
Subject: Re: Session is too sticky


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:

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 

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!


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
> 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
> redirecting the request to LB again after invalidating the Http
> (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:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message