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
