https://bz.apache.org/bugzilla/show_bug.cgi?id=62799
--- Comment #3 from Rainer Jung <rainer.j...@kippdata.de> --- I assume you are on RHEL 6 or 7? The Red Hat article unfortunately doesn't state, which version of mod_jk it is for. The man pages for connect() tells us: === Cite === EINPROGRESS The socket is nonblocking and the connection cannot be completed immediately. It is possible to select(2) or poll(2) for completion by selecting the socket for writing. After select(2) indicates writability, use getsockopt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect() completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure). === Cite === In our case the socket is non-blocking, because mod_jk puts the fresh socket into non-blocking mode. After connect() it does call select() and uses getsockopt() to check, whether connect completed successfully. I did a test compilation on RHEL 6 and RHEL 7 and verified that SO_ERROR is defined, so that code is executed. I can think of the following situations: a) select is documented to behave undefined, if the number of file descriptors goes above FD_SETSIZE, which on Linux is 1024. So it could be that it might return immediately without signalling an error. b) the clock jumping and letting select return much quicker than after 5 seconds with the connection not yet set up c) the connection taking longer than 5 seconds to get established To rule out a), you could try using version 1.2.44 but configure the connection setup timeout to "5" instead of "5000" due to the bug handling the config value in that specific version. Or you use the likely to get released soon version 1.2.46. These versions use poll() on RHEL which does not have the 1024 file descriptor limitations. There's no way around the select limitation using limits. It is a hard implementation limit of select on Linux. 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