I think I need to set my expectations of apache/mod_jk/tomcat realistically, so I'm hoping someone will be kind enough to clarify the following:
Setup: 2 clustered nodes running jboss4/tomcat5, one node running apache/mod_jk with sticky round-robin. a distributable web app is farmed out to the cluster. Consider the following scenario:
-User accesses webapp for the first time and is directed to node A
-session is established in A, and immediately replicated to B
-successive requests (let's say refresh) for that session keep going to A
-A goes down, next request goes to B
-A is brought back up, a bit later B goes down
-next incoming request goes back to A
-repeat the above steps
and so on...
I've done the above quite slowly, terminating jboss server instances, waiting for them to shut down, and then playing "user" role and hitting refresh. In that scenario, clustering worked perfectly! However, if user keeps hitting refresh about once a second, while the target node is being brought down, the user eventually sees a 404. A few clicks later, the user does get a valid response, served by node B (ie load balancing worked), but with a *new* session (i guess session replication didn't work).
Am I expecting too much from this setup? In practice, is there now way to ensure that a user will never see a 404 or lose a session as long as load balancer and at least one cluster node are alive? Is there a minimum time between user requests assumed? Or should one be able to blast a cluster using JMeter with low (say 300 millis) delay between successive requests, alternatively bring down nodes and still have the sessions preserved?
In my current jboss/tomcat config, session replication is set to "instant". Are there any setting in mod_jk.conf that can be used to make sure that a cluster node is alive and well *immediately* before sending a request to it?
