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

Aperta
  • Qualcosa non va?
#11,396 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@iloveeyjafjalla ci sta già lavorando.

Dal 13/10/2026.

  • #11397 di @iloveeyjafjalla — aperta

Valutazione

Difficoltà
1/5
Tempo stimato
Meno di un'ora
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
java
Ambito
backend, networking

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
22.7k
Fork
12k
Merge medio
3g 18h
PR unite (30g)
17

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/rocketmq

Tutte le issue di apache/rocketmq

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.