Hi Lari > 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 > 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? Increasing the parameter of Netty leads to more bytes that will be sent out, which are maintained by the Netty write-out buffer, but the broker still will face an OOM issue because the response is being generated. The purpose of the fix is not to avoid the channel being marked `not writable`, its purpose is to avoid too much memory usage because of a non-writable Netty channel. On Thu, Jul 10, 2025 at 4:54 PM Lari Hotari <lhot...@apache.org> wrote: > 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 > -- This email and any attachments are intended solely for the recipient(s) named above and may contain confidential, privileged, or proprietary information. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or reproduction of this information is strictly prohibited. If you have received this email in error, please notify the sender immediately by replying to this email and delete it from your system.
