Issue : mod_jk apparently does not use the retries parameter when “sticky_session_force” is set to false.
Configuration: Apache 2.0.53 (3 instances), mod_jk 1.2.28, 15 Tomcat 6.x instances Load balanced , No Session Replication Description: Ours is a high load application and using default value of sticky_session_force (in version 1.2.21) we observed too many session timeouts . This was because mod_jk would frequently get error from the tomcat instance (where session was established) after two retries and would send the request to another tomcat causing a session timeout. Setting sticky_session_force to true solved our session timeout issue but it had a side effect in situations where a particular tomcat is down or entire host is down. In such cases, users had to either clear cookies or close the browser to get to other working tomcat, otherwise they kept getting 503. Our web servers were overwhelmed by large number of users hitting refresh button. We are now upgrading to mod_jk 1.2.28. The ideal solution for us would be to set “sticky_session_force” to false and set the retries to 50, i.e. a number greater than 2 that will ensure that mod_jk does not give up too soon on a busy tomcat. What we observed is that, when sticky_session_force is true, mod_jk does try 50 times before marking tomcat in ERR state, but with the parameter set to false, it tries only two times before sending request to other tomcat, even if the retires parameter is set to 50. Is it possible at all to retry more than 2 times with sticky_session_force set to false? As a workaround, we thought of increasing the “retry_interval” to a larger number so that by the time two retries are completed, the tomcat might get free and the request will be served by the same tomcat instead of redirecting to another instance. This is actually less desirable as the tomcat might recover soon after the first retry but mod_jk will have to wait for a longer retry interval to try again. Frequent retries with shorter delays would work better. Please let us know your comments, suggestions. Thanks, Sameer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
