[Bug] ChangeLogLevel only touches the root logger, so it changes nothing with the shipped logback configuration

Aperta
#11,400 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.

  • #11401 di @iloveeyjafjalla — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
observability

Direzione di ricerca

Start at the ChangeLogLevel handler, where the root logger's level is set via loggerContext, then compare it with the component loggers in proxy/src/main/resources/rmq.proxy.logback.xml, which use additivity="false". Done means the requested level reaches those explicit-level loggers too, or docs/proxy-admin.md §8 is updated to state root-only behaviour. Open pull request #11401 already targets this, so coordinate with 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 (proxy module, admin gRPC surface, shipped logback configuration)

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

ChangeLogLevel reports success but changes nothing that is logged, because it only sets the root logger's level while the
shipped logging configuration pins every component logger.

The handler:

loggerContext.getLogger( ... Logger.ROOT_LOGGER_NAME).setLevel(logbackLevel);
remark = "log level changed to " + logbackLevel;

The configuration the distribution ships (proxy/src/main/resources/rmq.proxy.logback.xml, installed as
conf/rmq.proxy.logback.xml and selected by mqproxy through -Drmq.logback.configurationFile) gives 20 component
loggers their own level with additivity="false"
, for example:

<logger name="RocketmqProxy" additivity="false" level="INFO">
<logger name="RocketmqBroker" additivity="false" level="INFO">
...

In Logback a logger with an explicit level does not inherit the root logger's level, so after
ChangeLogLevel(DEBUG) every Rocketmq* logger keeps logging at INFO: the RPC answers
"log level changed to DEBUG" while the operator sees no additional log line — the on-demand troubleshooting switch the
proto documents ("dynamically change the runtime log level of the server without a restart") has no effect on the logs they
are trying to raise.

Steps to Reproduce
  1. Start the proxy as the distribution does (so the shipped rmq.proxy.logback.xml is in effect).
  2. Call ChangeLogLevel with DEBUG.
  3. The response says the level changed, but no DEBUG line from any org.apache.rocketmq.* logger appears, because the
    component loggers still carry their configured INFO level.
Expected behavior

The runtime change reaches the loggers whose level the configuration pinned (those are precisely the loggers with an
explicit level), so the server's log verbosity actually changes.

Actual behavior

Only the root logger is changed; the application loggers keep the configured level, and the RPC still reports success.

Additional context

Fix: apply the requested level to the root logger and to the loggers with an explicit level. If root-only behaviour is
preferred, the boundary belongs in docs/proxy-admin.md §8 instead — either way the current state (a documented switch that
silently does nothing with the shipped configuration) is not one of the two.

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.