Netty server holds back full response buffers until a flush or the high-water mark #1632

ChannelOutputStream (used for Netty response bodies) sends a full buffer with channel.write(...), not writeAndFlush(...). Netty then keeps those bytes in its outbound buffer until someone calls flush(), or until more than the write buffer high-water mark (64 KiB by default) is pending, at which point awaitInFlightBytes() flushes.

So a response whose producer writes one or two full buffers (32 KiB each by default) and then pauses sends nothing to the client until it resumes or ends. Entities written through IoUtils.copy, such as InputRepresentation, only flush at the end, so any slowly produced stream is affected. The class Javadoc says full buffers are "written as content messages", which suggests they should reach the peer.

Found while hosting smithy-java server protocols (#1631): a streaming payload that produced 64 KiB and then waited for the client to read it never reached the client, so the call stalled until the producer timed out.

Expected: a full buffer goes out at once (write and flush), so only the partially filled buffer waits for an explicit flush(), as with any buffered output stream.

🤖 Generated with Claude Code