[Bug] serverSocketBacklog is settable but the accept backlog is hard-coded to 1024 (regression of #3529)

Open
  • Is something wrong?
#11,396 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@iloveeyjafjalla is already working on this.

Since Oct 13, 2026.

  • #11397 by @iloveeyjafjalla — open

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
java
Domain
backend, networking

Research direction

The hard-coded ChannelOption.SO_BACKLOG value is in NettyRemotingServer#initServerBootstrap; compare it with the getter NettyServerConfig#getServerSocketBacklog(), which nothing in production reads. Done means the bootstrap option uses the configured backlog and NettyServerConfigTest still passes. A linked pull request (#11397) already targets this fix, so check it before starting.

Written by the indexing model from the issue text.

Description

Before Creating the Bug Report
  • I found a bug, not just asking a question, which should be created in GitHub Discussions.
  • I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.
  • 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:

private int serverSocketBacklog = NettySystemConfig.socketBacklog;
...
public int getServerSocketBacklog() { return serverSocketBacklog; }
public void setServerSocketBacklog(int serverSocketBacklog) { this.serverSocketBacklog = serverSocketBacklog; }

NettyRemotingServer#initServerBootstrap:

.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.

Dominant language
Java
Stars
22.7k
Forks
12k
Avg merge
3d 18h
Merged PRs (30d)
17

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/rocketmq

All issues in apache/rocketmq

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.