NettyDataBufferFactory.join(List<DataBuffer>) always creates a CompositeByteBuf, even for a single-element list of original buffers. This is generally worth optimizing but particularly necessary for Netty 4.1.32 where CompositeByteBuf is enforced to have at least two elements (see our current HttpServerTests failures on CI).
Rossen Stoyanchev, Arjen Poutsma, I hope this is ok the way I addressed it. As indicated by the recent HttpServerTests failures, we can run into situations with just a single element to join there, and Netty 4.1.32 has an assertion for at least two elements on any CompositeByteBuf.
The fix is correct, but not complete IMO. I would raise a question why maxNumComponents passed to CompositeByteBuf is equal to the number of buffers. The way maxNumComponents is used affects how buffers are consolidated. Some CompositeByteBuf methods' performance depend on how many buffers inside, but most do not. In particular, parsing the content sequentially doesn't really depend on that and so consolidation is rarely needed at all, meaning that maxNumComponents = Integer.MAX_VALUE seems to be quite safe default - unnecessary consolidation only adds more CPU load for copying data.
Oleg Alexeyev as far as I can see CompositeByteBuf will take the lesser of the given maxNumComponents or AbstractByteBufAllocator.DEFAULT_MAX_COMPONENTS which is 16. So wouldn't a value of Integer.MAX_VALUE get ignored?
Rossen Stoyanchev, I'm looking at netty 4.1.31 sources - this is what newList does for creating a ComponentList, consolidateIfNeeded() uses what's assigned to maxNumComponents, and that value is assigned as is. So, no, Integer.MAX_VALUE won't be ignored.