Tomcat6 clustering, loadbalancing ,session sharing ,failover

"balancer://" is used by apache mod_proxy_balancer and probably with mod_proxy_ajp who is another way to connect apache to tomcat ajp than mod_jk.

I can't tell you a lot on the load detection reliability but I learned this from my experience :

• Read carrefully the mod_jk directives manual
• Check the timeout parameters, this is very important. Default infinite "reply_timeout" is very bad: if a tomcat is dead apache will keep threads busy and you can be flooded.
• Read the mod_jk logs to look for errors
• Let apache handle directly static content with JkUnMount directive to give tomcat only needed requests.
• Use apache mod_cache if possible
• Use the mod_jk watch page to check what is happening on your connectors.

An article on mod_jk/proxy-ajp: http://thoughts.contegix.com/2009/02/02/mod-proxy-ajp-versus-mod-jk-round-1/

• The drawback of sticky-sessions is that with a growing number of nodes (in the range of > 100, > 1000) the probability of failure increases. Then it's preferable that it doesn't matter which node serves the request. However there are issues that have to be solved with sticky sessions differently, which of course depends on the requirements and the application (examples are session synchronization, preventing double submits, redirect-after-post etc.). Most often my own preference is to use sticky sessions as long there are a limited number of nodes. For 4 nodes personally I'd recommend using sticky sessions.
• We have used sticky-sessions and session replication via memcached-session-manager in production environments. memcached-session-manager was developed during the relaunch of tchibo.de (one of the biggest ecommerce-sites in germance), with the goal of both performance and scalability.
• We chose sticky-sessions for this application
  • because of better performance
  • the customer-requirements opted for sticky-sessions
  • the used web-framework was better suited for sticky-sessions.