Bug 40107 - JK should handle EAGAIN in jk_is_socket_connected()
JK should handle EAGAIN in jk_is_socket_connected()
Status: CLOSED FIXED
Product: Tomcat Connectors
Classification: Unclassified
Component: Common
unspecified
HP HP-UX
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-07-25 02:43 UTC by Jongjin Choi
Modified: 2008-10-05 03:09 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jongjin Choi 2006-07-25 02:43:24 UTC
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
Comment 1 Darryl Miles 2006-07-25 05:00:51 UTC
For the unenlightened what are the semantic differences ?  Is EAGAIN used for
read/accept operations and EWOULDBLOCK used for write/connect operations ?
Comment 2 Jongjin Choi 2006-07-25 05:11:36 UTC
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.



Comment 3 Shankar Unni 2006-07-25 21:05:57 UTC
(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
  }
Comment 4 Jongjin Choi 2006-07-31 12:07:30 UTC
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?
Comment 5 Mladen Turk 2006-08-25 07:37:38 UTC
jk_is_socket_connected() has been rewritten and does not use
non-blocking socket mode any more.
Please check the current SVN trunk.
Comment 6 Xuekun Hu 2007-06-20 20:54:00 UTC
(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
Comment 7 Rainer Jung 2008-01-01 16:51:27 UTC
Move a couple of fixed JK issues from resolved to closed.