This bug is a result of the testing that got done for a JIRA in Apache Geronimo
(Tomcat version) http://issues.apache.org/jira/browse/GERONIMO-2577

I am trying to setup a Tomcat cluster consisting of 3 Windows XP machines
running on Intel 32-bit platform. All 3 machines are on the same subnet.

Clustering is enabled at the application level or context level with the
following configuration files:
context_node1.xml
context_node2.xml
context_node3.xml
(edit line 25 of context_node*.xml, copy it into "conf" folder of Apache Tomcat
5.5.20 installation and rename it as "context.xml")

"server.xml" is kept unchanged.

Also deploy the sample application attached below:
servlets-examples-cluster_node1.war
servlets-examples-cluster_node2.war
servlets-examples-cluster_node3.war
(copy "servlets-examples-cluster_node*.war" into "webapps" folder of Apache
Tomcat installation and rename it as "servlets-examples-cluster.war")

Apache HTTP Server is used as the loadbalancer with the following configuration:
# AJP Connector for Tomcat
LoadModule jk_module modules\mod_jk.so
JkMount /servlets-examples-cluster loadbalancer
JkMount /servlets-examples-cluster/* loadbalancer
JkWorkersFile "C:/Program Files/Apache Software
Foundation/Apache2.2/conf/workers.properties"
JkLogFile "C:/Program Files/Apache Software Foundation/Apache2.2/logs/mod_jk.log"

# workers.properties
worker.list=loadbalancer,status
worker.node1.port=8009
worker.node1.host=AA.BB.CC.D1
worker.node1.type=ajp13
worker.node1.lbfactor=1

worker.node2.port=8009
worker.node2.host=AA.BB.CC.D2
worker.node2.type=ajp13
worker.node2.lbfactor=1

worker.node3.port=8009
worker.node3.host=AA.BB.CC.D3
worker.node3.type=ajp13
worker.node3.lbfactor=1

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2,node3
worker.loadbalancer.sticky_session=1
worker.status.type=status

Start Apache HTTP server followed by the Tomcat servers on all 3 nodes.

Try running the following:
http://Yourhost/servlets-examples-cluster - HttpSession is not used here, hence
no sticky session
http://Yourhost/servlets-examples-cluster/servlet/SessionExample - HttpSession
is used here, hence sticky session should be in effect

<Yourhost> is the hostname where HTTP server is running.

Running http://Yourhost/servlets-examples-cluster works as expected with
application getting served by different servers in the cluster in Round Robin
fashion.

However running http://Yourhost/servlets-examples-cluster/servlet/SessionExample
doesn't work as expected. I observe that session-ids are getting changed upon
hitting page-refreshes or upon adding attributes. I tried this
Application/Context level clustering in Tomcat multiple times, but same results
every time, with even sticky sessions not being in effect.

Note: 
Host level clustering on 3 or more nodes works correctly. I tested this by
moving the clustering info from "context.xml" to "server.xml". This time upon
running http://Yourhost/servlets-examples-cluster/servlet/SessionExample, I
observe that session ID is getting preserved across page refreshes and upon
adding new attributes. So I could proceed with testing the failover behaviour as
below:

1) Client "http://Yourhost/servlets-examples-cluster/servlet/SessionExample"
being served by Server-2.
2) Kill Server-2 and refresh the client. Client now being served by Server-3
with session id & state preserved.
3) Kill Server-3 and refresh the client. Client is now being served by Server-1
with session id & state preserved.
Also tried these:
4) Restart Server-2 and kill Server-1. Client is now being served by Server-2
with session id & state preserved.
5) Restart Server-3 and kill Server-2. Client is now being served by Server-3
with session id & state preserved.

So failover happening successfully across the 3-node cluster when Host Level
Clustering is used. But Context level clustering doesn't work.

- Shiva