Skip to main content

AJP/mod_jk load balancing in a cluster - sticky sessions not so sticky

3 replies [Last post]
Joined: 2007-05-24
Points: 0


I've setup a 2 instance cluster and I'm trying to get AJP/mod_jk loadbalancing to work. I followed the instructions here:

and was able to get the jvmRoute stuff working after reading this thread and installing the patch:

My problem now is that my sessions are not sticky, it keeps going round robin between the 2 instances instead of sticking to the same server instance. Using a firefox plugin, I had a look at the http request/response headers and it seems like I'm getting a new JSESSIONID back from the server with every request. I think this is the problem because every request starts a new session.

Any help will be greatly appreciated.


Here is my :


and the relevant part from httpd.conf:

JkWorkersFile /etc/libapache2-mod-jk/
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
JkMount /* loadbalancer

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2007-05-24
Points: 0

I finally figured it out, so I'm posting this if someone else has the same problem

There are basically 2 issues here :

1. sessions are not sticky - I missed this part in the mod_jk documentation :
"Furthermore the names of the workers which are managed by the balancer have to be equal to the jvmRoute of the Tomcat instance they connect with."
one I made the worker names and the jvmRoute properties the same for each cluster instance that solved the problem.
2. Each request gets a new session id. I read somewhere on a blog that you need to add the tag to your web.xml file, and then when you deploy the app into the cluster, you need to set availibility=true (default is false). This solved the session id issue

I must say it would be nice if everything was documented nicely in on place instead of being spread all over the show, glassfish docs, sjsas docs, glassfish wiki, glassfish forums, people's blogs etc.

Joined: 2004-12-01
Points: 0

Thanks for pointing this out!

I'm highlighting this information in my blog "How to Loadbalance GlassFish Cluster with Apache Loadbalancer" at

Under Configuration step 3, I now mention the following:

Make sure that the name of each worker equals the value of the
jvmRoute system property of the GlassFish instance to which the worker
connects. This convention makes it possible for an HTTP session to
remain sticky to the GlassFish instance on which the session was
created, or on which the session was last resumed.

and at the bottom of the blog, I've added this information:

As soon as the cluster instance to which an HTTP session has been
sticky has failed, the loadbalancer will route any subsequent requests
for the same HTTP session to a different instance. This instance will
be able to load and resume the requested session using the in-memory
session replication feature that has been available since GlassFish
V2. The in-memory session replication feature is enabled only for
those web applications that have been marked as distributable in their
web.xml deployment descriptor, and that have been deployed to the
cluster with the --availabilityenabled option of the asadmin deploy
command set to true (default is false).

I will also add this information to the GlassFish FAQ.


Joined: 2004-12-01
Points: 0