JDK-6343810 : connect in java/net/PlainSocketImpl.c should handle EALREADY
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.2_09
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2005-10-31
  • Updated: 2010-12-03
  • Resolved: 2006-02-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_12 b01Fixed 6Fixed
Related Reports
Relates :  
JDK-6670408 - testcase panics 1.5.0_12&_14 JVM when java.net.PlainSocketImpl trying to throw an exception
Description
In java/net/PlainSocketImpl.c line 347 there is a non-blocking connect() call.
errno is only being checked for EINPROGRESS. This should be improved to also
handle other error conditions. At least EALREADY. See the comments section for details.
The connect is actually blocking.
Comments
EVALUATION The reason why this fix is not needed on Linux is because Linux allows connect() to be restarted benignly. What I mean by this, is that the connect() is happening asynchronously (as specified by the unix spec), but if connect() happens to be called a second time, then instead of returning EALREADY (as specified by the spec) Linux just blocks the thread and behaves as if the connect() were being restarted.
19-01-2006
EVALUATION It seems the HPI needs to be changed as suggested so that connect() can be called repeatedly as before whenever EINTR is returned, but we check for: EISCONN --> connection was established EALREADY --> connection attempt is underway (converted to EINPROGRESS) Then in PlainSocketImpl socketConnect() we check for EINPROGRESS from blocking calls, and use select() to wait for the real error. I have tested this on mustang, and it seems to work.
20-12-2005
EVALUATION Instead of calling connect() again, hpi::connect should instead poll() the socket to wait for and determine the real error (or success) as the case may be. It's not clear to me whether this should be done on Linux as well. I suspect this is a problem on Solaris only.
11-11-2005
EVALUATION I'm waiting for a code snippet from Thomas to see exactly what the client code is doing, but it does seem now (contrary to what I said yesterday) that this is a regular untimed socket create and connect. The hpi seems to be restarting the connect call. And it seems this is not the right thing to do. I think the solution is probably for the HPI connect call to handle this more complicated maneuver internally, since that is the function of the HPI layer (to handle interruptible I/O). When we get confirmation that this is what the client is doing, I will reassign the bug to hostpot.
09-11-2005