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