https://bz.apache.org/bugzilla/show_bug.cgi?id=62799
--- Comment #6 from m...@blackmans.org --- (In reply to Rainer Jung from comment #5) > Hi Mark, > > (In reply to mark from comment #4) > > I know for a fact the connection is taking longer than 5 second to become > > established, because the backend is turned off. We're testing how mod_jk + > > Apache 2.4 handle the case where the backend becomes completely > > unavailable. > > OK, so the fact that mod_jk terminates the connection setup after 5 seconds > just works as expected. The admin has configured it and mod_jk reacts as > configured. Thanks. Unfortunately, I am still not making myself clear and I think it's because I am referring to two different two different scenarios. For the particular log messages above, the connection is showing failed due to EINPROGRESS long before the 5 second expiry, usually within milliseconds. I have two goals, both of which are admirably satisifed by mod_jk 1.2.42 and Apache 2.2, but failing miserably with mod_jk 1.2.42 and Apache 2.4 What I want: 1. Backend connection failures should be caught by a timeout, probably socket_connect_timeout 2. incomplete connections before the timeout expiry should never be flagged as failures. What I observe: If I set a socket_connect_timeout of 5000 milliseconds, loads of perfectly good backends are getting failed due to EINPROGRESS DESPITE the timeout not yet expiring. If I don't set a socket_connect_timeout at all (i.e. no timeout at all), then the request hangs indefinitely when the backend is missing. In other words, I have found no configuration that satifies goals 1 and 2 simultaneously, primarily, I believe, because the current code is treating EINPROGRESS as a failure way before the timeout expires. I can accept my interpretation of the underlying behaviours is wrong, but the fact is that mod_jk is marking backends down that are not down. I am open to suggestion on how I can demonstrate this behaviour more clearly that are achievable outside of our production environments. -- 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
