https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #3 from Mladen Turk <mt...@apache.org> 2009-03-06 00:06:07 PST --- Right the problem here is that we don't know weather the failed connection to backend was caused by Tomcat rejecting the connection because too busy or someone pulled the cable. What we did before was mark the entire worker in error if one of the connection failed, and that cause the exiting connections failed as well on next request. Eg. 100 connections to Tomcat is operational. 101st client comes in and it is rejected by tomcat (maxThreads=100). Before we would kill all 100 connections on next request because the 101st reported the Tomcat is 'in-error' Now, the drawback with the s->busy is that each client request will observe the connection delay (and that is much beter then presuming all connections are down) If we could reliably distinguish the return codes from jk_connect (reject or network totally down) we could then ship the s->busy check and mark the entire worker in error Anyhow, the proposed patch sets thing like there were before, and that will break more things cause the amount of problems caused by rejecting connections is far far far (did I say far) more common that someone pulling out the calble from a production server :) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
