On Thu, 10 Jul 2025 at 12:33, Yubiao Feng <yubiao.f...@streamnative.io.invalid> wrote: > 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.
This doesn't make sense: " its purpose is to avoid too much memory usage because of a non-writable Netty channel." The reason for this is that "writability" of the channel is solely about the amount of buffered bytes. Please re-read the earlier emails where I have explained this with references. Your PR is introducing a custom solution for controlling the size of the output buffer size. The correct way to handle this would be to configure ChannelOption.WRITE_BUFFER_WATER_MARK and perform the desired action in the channelWritabilityChanged callback method. In this case, the correct action would be to call org.apache.pulsar.broker.service.ServerCnxThrottleTracker's incrementThrottleCount/decrementThrottleCount instead of toggling autoread directly. I have explained the reason for this in previous emails (with reference to ServerCnxThrottleTracker javadoc). Why would you create a custom solution for controlling the size of the write buffer size when Netty already has a standard solution for controlling the write buffer size? -Lari
