Java NIO Framework Netty Tutorial (vii)-re-talk about the frequency of sending and receiving information

In the Java NIO Framework Netty Tutorial (v)-The problem of mismatched messaging times we tried to analyze a mismatch in the number of messages sent and received. At that time the author was still puzzled. So decide to learn the selector mechanism of Java NIO first.

After a simple understanding, the author boldly guesses and "arbitrarily" the cause of the problem.

First, the selector mechanism lets us register a time of interest, and then whenever that happens, it is passed to the receiving end. We have written three times, the receiver will definitely start three times.
Then, in the Netty implementation mechanism, there is a buffer buffer pool, the received information is cached inside, through a thread unified processing. That's the process of the buffer we're seeing.
In the Netty setting, there is a one-time maximum read byte size setting. Also, the event is triggered after the message in the buffer pool has been processed. Let's take a look at the code that reads the information in Netty:

View Sourceprint? 01. ByteBuffer bb = recvBufferPool.acquire(predictedRecvBufSize); 02. try  { 03. while  ((ret = ch.read(bb)) >  0 ) { 04. readBytes += ret; 05. if  (!bb.hasRemaining()) { 06. break ; 07. } 08. } 09. failure =  false ; 10. }  catch  (ClosedChannelException e) { 11. // Can happen, and does not need a user attention. 12. }  catch  (Throwable t) { 13. fireExceptionCaught(channel, t); 14. } 15.  16. if  (readBytes >  0 ) { 17. bb.flip(); 18.  19. final  ChannelBufferFactory bufferFactory = 20. channel.getConfig().getBufferFactory(); 21. final  ChannelBuffer buffer = bufferFactory.getBuffer(readBytes); 22. buffer.setBytes( 0 , bb); 23. buffer.writerIndex(readBytes); 24.  25. recvBufferPool.release(bb); 26.  27. // Update the predictor. 28. predictor.previousReceiveBufferSize(readBytes); 29.  30. // Fire the event. 31. fireMessageReceived(channel, buffer); 32. }  else  { 33. recvBufferPool.release(bb); 34. }

As you can see, if you do not read to the byte it will not trigger the event, so we may receive 2 or 3 times of information. (If the hair fast, parsing slow, after two times of information, a one-time read, 2 times, if the sending interval is long, the resolution is divided, received 3 times.) The reason should be that way. It's almost like we started guessing, just not sure.

Java NIO Framework Netty Tutorial (vii)-re-talk about the frequency of sending and receiving information