Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 21 Jun 2004 19:06:22 -0400
From:      Brad Karp <bkarp+@cs.cmu.edu>
To:        freebsd-java@freebsd.org
Subject:   nio, channels, and OP_CONNECT trouble?
Message-ID:  <20040621230637.B408343D45@mx1.FreeBSD.org>
next in thread | raw e-mail | index | archive | help 
I'm using ports/java/jdk14 on FreeBSD 4.9-RELEASE, built with JDK_VERSION
1.4.2 and JDK_PATCHSET_VERSION 5.

I'm running a rather large, complicated application (the Bamboo distributed
hash table, or DHT; if you're curious, http://www.bamboo-dht.org/) under
Java. I'm seeing behavior that seems very likely to be a bug in the FreeBSD
implementation of channels in java.nio. When I use OP_CONNECT to request
notification by selector.select() that a channel's connect() has completed,
the CPU utilization of the Java VM pegs at 100%, with top reporting over 30%
system time. A bit of poking around reveals that:

	1) the connect() actually completes, according to the server being
	   connected to
	2) in the client, select() is returning several times per millisecond,
	   but selector.selectedKeys() does *not* include the SelectionKey 
	   for the channel on which the connect() was called

So selector.select() is called over and over, and the CPU saturates. Has
anyone seen behavior anything like this? I can easily imagine that something
in the implementation of selecting on OP_CONNECT could be awry, given that
the underlying UNIX system call select(2) doesn't have any notion of
distinguishing "connect complete" from "writable."

More details follow, in case they are helpful.

nio supports nonblocking network connections with
SelectableChannels. I'm doing a nonblocking connect with:

            channel = SocketChannel.open();
            channel.configureBlocking(false);
            gateway = new InetSocketAddress(gnid.address(), gnid.port());
            channel.connect(gateway);

(Never mind about gnid; those address() and port() methods return what you
think they do.)

I'm then using a Selector and registering to be notified when the connect()
completes:

	SelectionKey skey =
	  channel.register(selector, SelectionKey.OP_CONNECT);

Thereafter, inside an event loop, I do:

	selector.select();
        Iterator i = selector.selectedKeys ().iterator ();
	while (i.hasNext ()) {
	    SelectionKey skey = (SelectionKey) i.next ();
	}

The selectedKeys returned do not include the SelectionKey returned in the
register() call above. It appears that the OP_CONNECT registration on channel
is causing a SelectionKey for a *different* channel to be returned.

Again, anyone seen similar behavior? If so, have a workaround or patch?

Many thanks,
-Brad, bkarp@cs.cmu.edu

P.S. One final note: I realize that there's a version 6 patchset, but after
reading the ChangeLog, I don't see any patches that since 5 that seem relevant
to the above.

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040621230637.B408343D45>