Read backpressure

[NiteshKant]

This is a dual of issue #25 which deals with write backpressure. It also depends on issue #27 which determines what gets written on a connection.

Key considerations

• When a read subscriber requests n items, how does it convert to the number of bytes read on the channel?
• Should we read exactly the number of items requested or we should apply heuristics on how much should be read?

[rstoyanchev]

We've experimented with basic read back-pressure support #33. To start simple, we set channel.config().setAutoRead(false) and have request(n) result in n calls to channel.read(). For each read, Netty reads as much as it can up to the size of the input buffer. In effect request(1) results in 1 ByteBuf from Netty where the size may vary (from what's available to read and up to the input buffer size).

The presence of codecs can change things. We took a couple of examples #32 with a line-based splitting decoder and a JSON decoder (which we copied from Netty 4.1). Both of these extend ByteToMessageDecoder that lets sub-classes decode the input message and add one or more Objects to a list, and then in channelReadComplete fires another read if autoRead=false and not enough data was received to decode even 1 object.

In effect, when TcpConnectionImpl issues 1 read, codecs will keep calling channel.read() as long as necessary to decode at least 1 Object. It also means that when TcpConnectionImpl issues 1 read, more than one objects may result. For example with the line-based codec:

$ printf "line1\nline2\n" | nc localhost <port>

For now we've added an IllegalStateException("Insufficient Capacity") when more messages are decoded than demand is requested. The thinking is that we could experiment with a Netty codec to deal with any overflow resulting from Netty codecs by buffering extra messages resulting from a single channel read.

Given this proposal, simple as it may be, do we need anything more in TcpConnectionImpl?

Regarding the key considerations in the original comment, we thought that further upstream, incoming messages can be aggregated or split as necessary rather than building that into TcpConnectionImpl. It's something we'll try to demonstrate next.