Motivation:
ByteToMessageDecoder requires using an intermediate List to put results into. This intermediate list adds overhead (memory/CPU) which grows as the number of objects increases. This overhead can be avoided by directly propagating events through the ChannelPipeline via ctx.fireChannelRead(...). This also makes the semantics more clear and allows us to keep track if we need to call ctx.read() in all cases.
Modifications:
- Remove List from the method signature of ByteToMessageDecoder.decode(...) and decodeLast(...)
- Adjust all sub-classes
- Adjust unit tests
- Fix javadocs.
Result:
Adjust ByteToMessageDecoder as noted in https://github.com/netty/netty/issues/8525.
Motivation:
RedisDecoder can get into an infinite loop while decoding bulk strings if the final \r and \n to indicate the end of content are split on ByteBuf boundaries.
Modifications:
- We should break out of the decode loop if remainingBulkLength is 0 and we don't have enough data to read EOL
Result:
No more infinite loop in RedisDecoder#decodeBulkStringContent.
Motivation:
Some codecs should be considered unstable as these are relative new. For this purpose we should introduce an annotation which these codecs should us to be marked as unstable in terms of API.
Modifications:
- Add UnstableApi annotation and use it on codecs that are not stable
- Move http2.hpack to http2.internal.hpack as it is internal.
Result:
Better document unstable APIs.
Motivation:
We need to ensure we not retain the buffer until readEndOfLine(...) completes as otherwise we may leak memory in the case of an exception.
Modifications:
Only call retain after readEndOfLine(...) returns.
Result:
No more leak in case of exception while decoding redis messages.
Motivation:
- `RedisBulkStringAggregator` raises errors for multiple null bulk strings.
- Null or empty bulk string has no content, but current `RedisDecoder` generates header and contents.
Modifications:
- Fix decoding null bulk string of `RedisDecoder` for `RedisBulkStringAggregator`.
Result:
- Fixes#5184.
