NIO CPU Anomaly

[JSParker1]

I have recently run into an anomaly using the NIO packages in a
multithread thick client. Can anybody help?
The app opens a few of IP connection (about 20) for two way
communication. It was recently migrated across to use the NIO API and
this has caused the client CPU to hit 100% even when idle. On the old
IO packages this was <1% CPU.
(This is my first newsgroup posting so please let me know if I should
include more/less info).


Nick

 

[Gordon Beaton]

I have recently run into an anomaly using the NIO packages in a
multithread thick client. Can anybody help?

The app opens a few of IP connection (about 20) for two way
communication. It was recently migrated across to use the NIO API
and this has caused the client CPU to hit 100% even when idle. On
the old IO packages this was <1% CPU.

(This is my first newsgroup posting so please let me know if I should
include more/less info).

Well, generally you should post a relevant section of code, ideally
something short that compiles and has the problem you describe.

However I suspect that you need to remove the SelectionKey from the
selection Set, or select() will immediately return the same key again
(even though it might not be ready). Something like this:

SelectionKey sk;

Set ready = s.selectedKeys();
Iterator i = ready.iterator();

while (i.hasNext()) {
sk = (SelectionKey)i.next();
i.remove(); // do this!

if (sk.isAcceptable()) {
// accept incoming connection
}
else if (sk.isReadable()) {
// read from SocketChannel
}
// etc
}

/gordon

 

[Stefan Schulz]

Well, generally you should post a relevant section of code, ideally
something short that compiles and has the problem you describe.

However I suspect that you need to remove the SelectionKey from the
selection Set, or select() will immediately return the same key again
(even though it might not be ready). Something like this:
/gordon

Another thing that comes to mind is that you might have switched some
Channel to non-blocking IO, and read it as if it was blocking, which
results in hundreds of read-calls all returning no new data.

 

[Esmond Pitt]

You should also generally *not* select on OP_WRITE unless you have just
encountered a short write, as sockets are almost always writable and
this will cause select() to return immediately.