United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6343810 connect in java/net/PlainSocketImpl.c should handle EALREADY
JDK-6343810 : connect in java/net/PlainSocketImpl.c should handle EALREADY

Details
Type:
Bug
Submit Date:
2005-10-31
Status:
Resolved
Updated Date:
2010-12-03
Project Name:
JDK
Resolved Date:
2006-02-21
Component:
core-libs
OS:
solaris_9
Sub-Component:
java.net
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2_09
Fixed Versions:
1.4.2_12 (b01)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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

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.
                                     
2005-11-09
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.
                                     
2005-11-11
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.
                                     
2005-12-20
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.
                                     
2006-01-19



Hardware and Software, Engineered to Work Together