OP_CONNECT, connect, and finishConnect fail

[Johannes Rudolph]

Hi there,

I don't know what the right channels are to report bugs for the (Open)JDK.
The bug database seems to be completely unmaintained and the last time I
tried to file a bug I never got any answer and the report never showed up.

This is basically a follow up to
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6371630<http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=6527950b85b5a7698791fa474596?bug_id=6371630>


The problem is that under Linux for outgoing connections bad things happen
if you select for OP_CONNECT before even attempting the connect. The
sequence of calls is this:

 * SocketChannel.open
 * ch.configureBlocking(false)
 * ch.register(selector, OP_CONNECT)
 * selector.select() instantly returns and reports the channel as connected
(it doesn't matter if you do the actual select call after the connection
attempt)
 * ch.connect(unrespondingHostAddress) which returns false
 * ch.finishConnect() which now always returns true, the OS-level socket
itself, however, never received any response from the peer for its SYN
packet
 * ch.isConnected() returns true
 * if the host would eventually establish the connection the socket would
be usable (as OP_READ and OP_WRITE still work as intended), so the main
problem is that a connection is reported as established when, in fact, it
may never make any progress with connection establishment

Of course, you could argue that registering for OP_CONNECT before calling
connect is a user error but is neither forbidden by the documentation nor
in any way prevented at runtime. All of the later behavior of
`finishConnect` makes no sense at all. Also the actual call-sequence can
usually be much more complicated in a common multi-threaded setting so the
actual calls registering the channel to the selector and the connection
attempt may be executed concurrently for some reasons making this bug even
harder to find.

Here's an standalone example exhibiting the behavior:
https://gist.github.com/jrudolph/6535400

We discovered the problem here:
https://www.assembla.com/spaces/akka/tickets/3602-io--tcp-connection-establishment-always-succeeds-even-if-endpoint-never-answers<https://www.assembla.com/spaces/akka/tickets/3602-io--tcp-connection-establishment-always-succeeds-even-if-endpoint-never-answers#/activity/ticket:>

Cheers,
Johannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130912/567fc83b/attachment.html>