https://bz.apache.org/bugzilla/show_bug.cgi?id=62799
--- Comment #5 from Rainer Jung <rainer.j...@kippdata.de> --- 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. Note that even if a backend service is down, a connection setup to it often fails quickly: if the node is reachable but no service is bound to the given port (eg. process crash) and also if the node is not reachable at all due to orderly shutdown. The typical cases for slow connection setup are either packet drop due to some overloaded network component or bad cabling, or if you cut or unplug a cable, or if a machine stops in an abnormal way (power outage etc.). Then the last network hop that's reachable on the way to the backend still has the next MAC address in its table and thinks the next hop is reachable. It takes some time before the MAC gets out of the table and the component can immediately return with a "not reachable". When a backend interface is shutdown normally, it signals the other side, so that the MAC address gets immediately removed. > My point, which seems might not be clear yet, is that EINPROGRESS should > never be a connection failure while a socket is still in progress, because, > by definition, it has *NOT YET* timed out. EINPROGRESS is a system level errno indicating the socket status. From the point of view of the system, the connect is still in progress. Is has not timed out in the operating system. Since the admin has configured mod_jk to not wait any longer, the connect has timed out in mod_jk, so mod_jk stops connection setup and reports the mod_jk timeout as a mod_jk error. The errno 115 is just an additional detail info. That info is helpful here, because it shows us that the socket connect had not yet finished with error or success, when the mod_jk timeout fired. > The socket state should change from EINPROGRESS to something else after the > timeout expires, to indicate connection failure. EINPROGRESS should never > never be the cause of connection failure, ever, in my opinion. I think we can not set the internal OS socket state. What is documented is, that we should close the socket for clean up. That's what we actually do. EINPROGRESS is not the cause of the connection failure. The cause is the application software (mod_jk) timeout the admin has explicitly configured. After the timeout the socket connect is in state EINPROGRESS, so it has not completed so it failed to complete faster than the configured timeout. That's an error from the point of view of mod_jk. So what do you suggest should happen instead? If you do not want an error, increase the connect timeout and accept to wait and hang longer if connects are slow. Or do you suggest a different way of logging? Or do you want a connection setup timeout in mod_jk to not get handled as an error? What else should it be? Regards, Rainer -- 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
