https://bz.apache.org/bugzilla/show_bug.cgi?id=62799
--- Comment #7 from Rainer Jung <rainer.j...@kippdata.de> --- (In reply to mark from comment #6) > (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. Making that clear from the beginning would have saved quite some time used for responses :( > For the particular > log messages above, the connection is showing failed due to EINPROGRESS long > before the 5 second expiry, usually within milliseconds. OK, here I suggest to check using 1.2.44 (and switching temporarily to the value 5 due to the "seconds instead of milliseconds" bug in 1.2.44) or 1.2.46 pre-release and recheck. It could well be that the poll() system call used there for RHEL is more reliable due to the known limitations of select() on Linux. > 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 I remember you said 2.2 with prefork. So you could also cross check with 2.4 and prefork. Because with prefork, theres much less file descriptors in use. If prefork and 2.4 work well, that might be another hint at using the poll() impl provided by 1.2.44+. > What I want: > > 1. Backend connection failures should be caught by a timeout, probably > socket_connect_timeout For clarity: socket_connect_timeout is not a generic connection timeout, it is instead a timeout for socket connect, that means only for the process of setting up a new connection (connect() system call). That's what it is meant for, nothing else. If you need to tackle more types of "connection failures", there's probably other features handling them, but not socket_connect_timeout. > 2. incomplete connections before the timeout expiry should never be flagged > as failures. Agreed but as I wrote before, this could happen due to the select() limitation in 1.2.42 (not sure but could be), or time jumping forward. > 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. How do you know that "the timeout" is "not 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. More precisely *setup of new connections* will hang (if the network doesn't respond with a no route to host or similar). > 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. As I tried to explain several times now: the current code handles EINPROGRES as a normal return value and after EINPROGRESS waits for the timeout to happen and then checks the socket status again. We might have done this wrong, but it is not as obvious as you think. > 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. We could add some lines to the code which track the connection setup in mod_jk and log the details only if the setup fails due to socket_connect_timeout. But before doing this I would be interested in the behavior of recent code (1.2.44 with config "5" or 1.2.46 pre-release). 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
