Re: Java NIO Strategy

To save further discussion I'll deal with this blog here in its entirety.

 > if ((key.readyOps() & SelectionKey.OP_ACCEPT) ==
 > SelectionKey.OP_ACCEPT){
 > handleAccept(key);
 > } else if ((key.readyOps() & SelectionKey.OP_READ) ==
 > SelectionKey.OP_READ) {
 > handleRead(key);
 > }
 > Next in handleRead(key), you will do:
 >
 > socketChannel = (SocketChannel)key.channel();
 > while ( socketChannel.isOpen() &&
 > (count = socketChannel.read(byteBuffer))> -1)){
 > // do something
 > }

So far so good. Obviously the channel must be registered for OP_READ
otherwise we would never have got here.

 > Well, the scary part is the // do something.
 > Gold Candidate for a Memory Leak (GCML)
 > At this stage, socketChannel is ready to read bytes. Hence you invoke
 > socketChannel.read(byteBuffer), and you find that you haven't read
all > the bytes from the socket

How can you possibly find that? or does he mean that you find you
haven't read the entire request?

 > so you decide to register the SelectionKey back to the Selector by
 > doing:

 > selectionKey.interestOps(
 > selectionKey.interestOps() | SelectionKey.OP_READ);

What for? OP_READ IS ALREADY REGISTERED! How else did we get here?

 > and...and...and do something like:
 >
 > selectionKey.attach(...)
 >
 > Boum...the little ... is where the devil is hiding!

etc etc etc, all the stuff about how selection keys with attachments
that never fire events are memory leaks. Well, such a selection key is
*itself* a memory leak, and you have to scan for that case anyway. So
when you scan the selector's keyset for idle keys, you've just solved
the entire imaginary problem.

You also have to maintain session context anyway, and you have to hold
this somewhere, and the selection-key attachment is as good a place as
any. Better IMHO.

 > How do I retrieve the SocketChannel if I don't attach it to my
framework object.

A non-problem. SelectionKey.channel().

 > How do I deal with incomplete socketChannel read.

 > When you do socketChannel.read(), you can never predict when all
bytes > are read from the socket buffer. Most of the time, you will have to
 > register the SelectionKey back to the Selector, waiting for more bytes
 > to be available.

Why? It's already registered.

 > In that case, you will most probably attach the incomplete ByteBuffer
 > to the SelectionKey, and continue adding bytes to it once the
 > SelectionKey is ready.

I would already have attached a session object when I accepted the
connection, and the ByteBuffer would be part of that. Possibly two, if I
want to maintain a read buffer and a write buffer.

 > Instead, I would recommend you register the
 > SelectionKey to a temporary Selector (I will blog about this trick in
 > more details):
 >
 > try{
 > SocketChannel socketChannel = (SocketChannel)key.channel();
 > while (count > 0){
 > count = socketChannel.read(byteBuffer);
 > }
 >
 > if ( byteRead == 0 ){
 > readSelector = SelectorFactory.getSelector();
 > tmpKey = socketChannel
 > .register(readSelector,SelectionKey.OP_READ);
 > tmpKey.interestOps(tmpKey.interestOps() |
SelectionKey.OP_READ);

The last line is redundant.

 > int code = readSelector.select(readTimeout);

At this point the entire application, with its 10,000 connections whose
liveness we are so concerned about, has been stalled for up to 15
seconds waiting for more data from just one channel. This suggestion is
just plain stupid.

 > tmpKey.interestOps(
 > tmpKey.interestOps() & (~SelectionKey.OP_READ));

What's this for?

He doesn't show why this entire extra Selector isn't a memory leak in
itself. I suppose the selector factory is doing something about that, in
which case this line might be important. Or not. I can imagine the
selector factory taking care of that itself actually.

But I certainly wouldn't be doing any of this.

 > With this trick, you don't need to attach anything to the SelectionKey.

With this trick you have just lost all concurrency and scalability. Your
server has just dedicated itself to a single client for 15 seconds.

 > So here you gonna need to decide based on your use of NIO: do you
want a dormant ByteBuffer attached to a SelectionKey or a Thread
blocking for readTimeout.

Clearly a non-decision. We are using NIO because we want scalability.

 > In Grizzly, both approaches can be configured, but by default the
thread will block for 15 seconds and cancel the SelectionKey if the
client isn't doing anything.

Remind me to avoid Grizzly in that case.

 > You can configure Grizzly to attach the ByteBuffer if you really like
to use memory :-) . We did try on slow network, with broken client,
etc., and blocking a Thread scale better than having a dormant ByteBuffer,

This claim is not credible.

 > [he then goes on to describe an architecture where you start more
threads to handle these incomplete reads]

Once again losing scability in favour of more threads depending on load.

 > Wow that one was very long. Agree, disagree?.....

I disagree completely. NIO is just not that complicated to use well.
Considering this effort comes from within Sun it is really quite
shocking that it exhibits little if any understanding of what NIO really
does or how to use it.