I am using mod_jk 1.2.14 with SUN ONE web server 6.1 on HP-UX. I found that this error message on mod_jk log file. ------------------------------------------------------- [화 7월 19 15:27:55 2006] [16718:0016] [info] jk_ajp_common.c (1178): Socket 35 is not connected any more (errno=11) [화 7월 19 15:27:55 2006] [16718:0016] [info] jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [화 7월 19 15:27:55 2006] [16718:0016] [info] jk_ajp_common.c (1178): Socket 34 is not connected any more (errno=11) [화 7월 19 15:27:55 2006] [16718:0016] [info] jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [화 7월 19 15:27:55 2006] [16718:0016] [info] jk_ajp_common.c (1225): All endpoints are disconnected or dead ------------------------------------------------------------- Digging into mod_jk source code, jk_is_socket_connected() in jk_connect.c seems to have a problem. In HP-UX, non-blocking read() would fail with errno 11 (EAGAIN) instead of EWOULDBLOCK. Reviewing errno.h and related files in several platforms, I found that EWOULDBLOCK is same as EAGAIN in Linux, but NOT in HP-UX. I feel that EAGAIN should be treated same as EWOULDBLOCK in jk_is_socket_connected(). -- Jongjin
For the unenlightened what are the semantic differences ? Is EAGAIN used for read/accept operations and EWOULDBLOCK used for write/connect operations ?
Darryl, I don't know exactly what the difference is between EAGAIN and EWOULDBLOCK. As a quick google search result, I got following link : http://www.codecomments.com/archive286-2005-10-641948.html That may be helpful. Thanks for your interest.
(In reply to comment #2) > http://www.codecomments.com/archive286-2005-10-641948.html That whole discussion is utterly bizarre and pointless - the thread drifts off into arguing about how to handle situations where EWOULDBLOCK is not defined. The issue here is that on some OSes, the two constants have different values, and read() can return either value depending on the circumstances of how the socket was set up. (But from a semantic point of view, what it's saying in both cases is that there is a need to retry the operation, which is the important thing to take away. See http://devrsrc1.external.hp.com/STKS/cgi-bin/man2html?manpage=/usr/share/man/man2.Z/send.2 - the link in the quoted thread) On other OSes, the two constants are the same value. Are there any on which EWOULDBLOCK is not even defined? I don't think so. In any case, the code could be fixed as: if (errno == EAGAIN #if defined(EWOULDBLOCK) && EWOULDBLOCK != EAGAIN || errno == EWOULDBLOCK #endif ) { // try again later }
Seeing manpages of read() from various platforms(Linux, HP-UX, Solaris, AIX), I found that EWOULDBLOCK is not described in read()'s error code. Anyway, I think Shakar's patch (in comment #3) is right. Is there any plan to apply that patch?
jk_is_socket_connected() has been rewritten and does not use non-blocking socket mode any more. Please check the current SVN trunk.
(In reply to comment #5) > jk_is_socket_connected() has been rewritten and does not use > non-blocking socket mode any more. > Please check the current SVN trunk. Do you have any other reason why not using non-blocking socket mode? From my view, non-blocking socket should have better performance. In my stress test, I saw 2x performance boost with non-blocking vs. blocking socket. To fix this issue on HP-UX, I think the patch (in comment #3) is good. Thx, Xuekun
Move a couple of fixed JK issues from resolved to closed.