Re: Java NIO Strategy
mearvk wrote:
[Quote from:
http://weblogs.java.net/blog/jfarcand/archive/2006/06/tricks_and_tips.html]
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 (or you are ready to handle the next
request), so you decide to register the SelectionKey back to the
Selector by doing:
selectionKey.interestOps(selectionKey.interestOps() |
SelectionKey.OP_READ);
Yet another thing I don't understand in these blogs. You should only
have gotten here if you were already registered for OP_READ. Just stay
that way!
Boum...the little ... is where the devil is hiding! What you are
attaching to the SelectionKey is very dangerous, because there is some
probability that your SelectionKey might never return to a
ready-operation state, leaving the SelectionKey and its evil attachment
forever inside the Selector keys set.
Rubbish. This can only happen if you don't do the idle processing I
described in an earlier posting. *That's* the devil.
Does this make sense? If you explicitly tell your program to re-insert
the SelectionKey back into the key set and we know it has more data to
be read (per the premise), then unless your server is completely
pegged, wouldn't it *always* return to a ready-operation state?
Only if more data arrives.
The 'premiss' is meaningless: '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 (or you are ready to handle the next
request)'. How can you find you haven't read all the bytes from the
socket, except by trying another read? And this case even if it existed
is logically very different from the case where you are ready to handle
the next request.
Could you do:
if((count = socketChannel.read(byteBuffer))> -1)
{
//read into temp buffer
}
else
{
//forward buffer
}
So that your time in the readFromSocketChannel method is
shorter/fairer? This assumes that the key gets placed back into the
Selector key set and eventually (depending on load)gets re-handled
promptly.
I agree and this is what I do except that I don't do all this key
manipulation. Also I check for 0 and -1 separately as they are very
different cases.
I register and de-register as follows (assuming this is a server):
(a) when I get an OP_ACCEPT and accept a channel I register it for OP_READ.
(b) When I've had enough read events and read enough data to constitute
a complete request (an interesting problem in itself) I deregister for
OP_READ and pass the request off for processing. If I get EOF instead I
close the channel, physically and logically.
(c) When I get the response back from wherever it was processed I
attempt a write. If this doesn't succeed completely I register OP_WRITE.
Any time I get OP_WRITE and the write succeeds completely I deregister
OP_WRITE and register OP_READ.
(d) I do the reads and writes in a single attempt without looping, for
better fairness between channels.
(e) In the idle loop, if I find a channel that has been registered for
OP_WRITE for too long I close it physically and logically and abort the
transaction internally. If I find a channel that has been registered for
OP_READ for a long time I might time out the connection, depending on
the application. If I find a channel that hasn't been registered for
*anything* for a long time, it means that some transaction is still in
progress and I might want to inquire into why it is taking so long.
(f) If the transactions are such that there are done in-line rather than
in separate worker threads, i.e. inline at the OP_READ site, when I get
the response I don't write it straight away, I register OP_WRITE on the
channel and deregister OP_READ, and let the reply be written out on the
next iteration of the Selector. Again, this promotes fairness among
channels.
The reason for deregistering OP_READ in each case above is that you
usually can't logically handle another request from the same channel
until you've completed the previous one and written the reply. So you
should quench that channel. Otherwise you have to read the new data, and
put it somewhere, which takes memory. Better to stop reading and,
eventually, stall the sender, by closing the TCP window. It's a bit like
the principle of letting passengers get off the bus before the new ones
get on.
The really scary thing about these blogs is that this guy apparently
works for Sun Microsystems. Here's another gem I noticed:
while (bb.hasRemaining()) {
int len = ch.write(bb);
if (len < 0)
throw new EOFException();
}
etc. I've already commented that write() never returns a negative
result. What fascinates me now is the concept of throwing an
EOFException when *writing*. This seems to have been lifted holus-bolus
from the old NIO tutorial code, which was obviously cut-and-pasted from
the read code, and which was corrected at my request last year as being
meaningless.