On Thu, 10 Jul 2025 at 05:47, Yubiao Feng
<yubiao.f...@streamnative.io.invalid> wrote:
> Highlight: The purpose of the fix is to solve the high memory usage caused
> by a single channel when it is not writable. The fix is not in order to
> limit a broker-level memory usage.

In Netty, the channel writability state is controlled by the
WriteBufferWaterMark settings, which are configured through the
server's child channel option ChannelOption.WRITE_BUFFER_WATER_MARK.
This is typically set during server bootstrap configuration like this:

ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.childOption(ChannelOption.WRITE_BUFFER_WATER_MARK,
    new WriteBufferWaterMark(lowWaterMark, highWaterMark));

The concept of "writability" means that when the number of buffered
bytes exceeds the high water mark setting, Channel.isWritable()
returns false. Once the buffered bytes drop below the low water mark,
the writability state changes back to true.
For reference, see:
https://netty.io/4.1/api/io/netty/channel/WriteBufferWaterMark.html

> Increasing the config will only increase the number of active packet losses
> and packet retransmissions of TCP, which is of no benefit to the system. It
> merely shifts the memory pressure to the system kernel, the implementer of
> the TCP protocol

Netty's channel writability state operates independently of TCP-level
flow control. The WriteBufferWaterMark settings control Netty's
internal buffer management and the isWritable() state, which is
separate from TCP's sliding window mechanism and flow control at the
network layer.

Have you considered this mechanism in your PR?

-Lari

Reply via email to