From my test, this scenario usually happens when the payload in the retrieved message is huge, such as the payload of data dictionary domain.

In the example code, ChannelSession::readInt(...) method has a do/while loop which calls the read method while the readArgs.readRetVal() is more than TransportReturnCodes.SUCCESS (0).

private int readInt(PingHandler pingHandler, ResponseCallback callbackclient, Error error)
    {
        TransportBuffer msgBuf;
        do /* read until no more to read */
        {
            msgBuf = channel.read(readArgs, error);
...

        }
        while (readArgs.readRetVal() > TransportReturnCodes.SUCCESS);
...
}

Channel.read() method not only reads the raw data from network but it also processes the raw data and returns the buffer.

When the returned buffer is null and readRetVal return a value which is more than zero, it indicates the more raw data needs to be read from the network in order to create the complete buffer.

The code is designed to do this as fast as possible. Therefore, it is possible that the read method method is called too fast without reading any raw data from the network. You can verify this by print readArgs.uncompressedBytesRead() and readArgs.readRetVal() when the returned buffer is null.

You can see that there are a lot of calls that uncompressedBytesRead returns zero.

### Read return null: uncompressedBytesRead: 0, readRetVal:3472
#### Read return null: uncompressedBytesRead: 0, readRetVal:3472
#### Read return null: uncompressedBytesRead: 0, readRetVal:3472
#### Read return null: uncompressedBytesRead: 0, readRetVal:3472
#### Read return null: uncompressedBytesRead: 6138, readRetVal:2142
#### Read return null: uncompressedBytesRead: 6130, readRetVal:152
#### Read return null: uncompressedBytesRead: 0, readRetVal:152
#### Read return null: uncompressedBytesRead: 0, readRetVal:152
#### Read return null: uncompressedBytesRead: 0, readRetVal:152
#### Read return null: uncompressedBytesRead: 0, readRetVal:152
#### Read return null: uncompressedBytesRead: 0, readRetVal:3624
#### Read return null: uncompressedBytesRead: 0, readRetVal:4292
#### Read return null: uncompressedBytesRead: 0, readRetVal:4292
#### Read return null: uncompressedBytesRead: 0, readRetVal:4292
#### Read return null: uncompressedBytesRead: 0, readRetVal:4292
#### Read return null: uncompressedBytesRead: 0, readRetVal:4292
#### Read return null: uncompressedBytesRead: 0, readRetVal:4292
#### Read return null: uncompressedBytesRead: 0, readRetVal:4292
#### Read return null: uncompressedBytesRead: 0, readRetVal:4292
#### Read return null: uncompressedBytesRead: 6138, readRetVal:2294

From the code, this is expected because it is designed to get the buffer as fast as possible.

However, if you would like to avoid this, you can add a short sleep for this condition. This can reduce the number of channel read called.

if(msgBuf == null && readArgs.readRetVal() > TransportReturnCodes.SUCCESS){
try {
	Thread.sleep(5);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
 e.printStackTrace();
 	}
 }

#### Read return null: uncompressedBytesRead: 6138, readRetVal:2142
#### Read return null: uncompressedBytesRead: 6130, readRetVal:47072
#### Read return null: uncompressedBytesRead: 6138, readRetVal:40934
#### Read return null: uncompressedBytesRead: 6138, readRetVal:34796
#### Read return null: uncompressedBytesRead: 6138, readRetVal:28658
#### Read return null: uncompressedBytesRead: 6138, readRetVal:22520