iloveeyjafjalla opened a new issue, #11396: URL: https://github.com/apache/rocketmq/issues/11396
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Runtime platform environment OS: any (remoting module; broker / nameserver / proxy accept backlog) ### RocketMQ version branch: develop Git commit id: a7edeecfb (2026-10-13; the files are unchanged by that commit) ### JDK Version Compiler: Temurin 1.8.0_504 (target 1.8, same as CI) ### Describe the Bug `serverSocketBacklog` is settable (field, getter/setter and the `rocketmq.remoting.socket.backlog` system property), but the accept backlog is a hard-coded literal, so the option silently does nothing. `NettyServerConfig`: ```java private int serverSocketBacklog = NettySystemConfig.socketBacklog; ... public int getServerSocketBacklog() { return serverSocketBacklog; } public void setServerSocketBacklog(int serverSocketBacklog) { this.serverSocketBacklog = serverSocketBacklog; } ``` `NettyRemotingServer#initServerBootstrap`: ```java .option(ChannelOption.SO_BACKLOG, 1024) ``` `getServerSocketBacklog()` has no production reader anywhere in the repository — the only caller is `NettyServerConfigTest`, which asserts that the setter stores the value. This is a regression of #3528/#3529 ("The value of ChannelOption.SO_BACKLOG can not be hard-coded", 2021), which made the bootstrap read this option; the RIP-31 BrokerContainer refactor reverted that single line to the literal while keeping the field, the getter and the system property. Impact: an operator raising the backlog for a broker/nameserver/proxy that must absorb connection storms gets no change at all — the listen queue stays at 1024, so bursts can be refused (clients see connection resets/timeouts) despite the tuned configuration, and the value reported back by the config dump looks as if it were in effect. ### Steps to Reproduce 1. Set `serverSocketBacklog=65535` in `broker.conf` (or `-Drocketmq.remoting.socket.backlog=65535`). 2. Start the broker and inspect the server bootstrap: `ChannelOption.SO_BACKLOG` is `1024`, not `65535`. 3. A connection burst larger than 1024 pending accepts is refused by the OS, exactly as with the default. ### Expected behavior The bootstrap uses the configured backlog, as it did before the RIP-31 refactor. ### Actual behavior The literal `1024` is used; the option is inert. ### Additional context Fix: pass `this.nettyServerConfig.getServerSocketBacklog()` to the bootstrap option, as #3529 did. `NettyRemotingServer` is the only place a listening socket is created inside this module, so the single line restores the option for broker, nameserver and the proxy's remoting server. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
