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

Source: Internet
Author: User

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

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.