Tomcat ajp Connector Sticky Load Balance Policy thwarted
romalley Aug 23, 2002 10:41 AMThe Tomcat isapi_redirect.dll uses a Load Balance Policy that looks for a token in the session cookie. That token must be created by Tomcat when configured to do so. Here's a message I posted to the bottom of another thread but I am re-posting as a separate topic in hopes that Sacha will see it here:
----------------------------------
Sacha
1) For the Jakarta Tomcat redirector dll plugin, there is a simple piece of round robin load balancing that Tomcat must do. I think this redirector does it's round robin work by looking at a portion of the session cookie. To control this piece of the cookie, there is field called 'jvmRoute' that Tomcat places at the end of the session ID. The Tomcat configuration approach is to put the jvmRoute attribute into the Engine entry in the tomcat4-service.xml file like this:
Then, for the load balance redirector within the worker.properties file, you set up a worker with the same name like this:
worker.serverOne.port=8009
worker.serverOne.host=localhost
worker.serverOne.type=ajp13
worker.serverOne.cachesize=20
worker.serverOne.lbfactor=2
Then, you can see in my example the session.getId() method returns a value like this:
7F9086AFF3E0E6DDE974452847CBB3BB.serverOne
Sticky load balancing works -- all requests for this session are forwarded to the worker called serverOne.
But when I use the jbossha-httpsession.sar, the session does NOT have the jvmRoute in it, instead the session looks like this with clustering turned on:
dc9A8mxS88aHU8Z8C3sXfA**
So, the IIS redirector does not know what to do because it does not find the .serverOne at the end of the session. It no longer does sticky load balancing.
2) I was somewhat incorrect in the way I reported it's behavior. What it actually does, is to round robin every request when clustering is turned on. I think this is not so bad as long as our application doesn't modify the session for every request. I might leave it alone and leave the session replication so it replicates immediately (the default I think). We'll load test and see if there is a performance hit.
3) Ideally, the jbossha-httpsession would continue to append the 'jvmRoute' of the 1st server hit to the end of the session id and I think sticky load balancing for the Tomcat redirector would be fixed.
Bob O'Malley