[Bug] ChangeLogLevel only touches the root logger, so it changes nothing with the shipped logback configuration
I maintainer di solito rispondono entro 1 giorno
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
- Start the proxy as the distribution does (so the shipped
rmq.proxy.logback.xmlis in effect). - Call
ChangeLogLevelwithDEBUG. - The response says the level changed, but no
DEBUGline from anyorg.apache.rocketmq.*logger appears, because the
component loggers still carry their configuredINFOlevel.
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
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/rocketmq
-
[Bug] RemotingHelper.connect swaps the socket send and receive buffer configurationForse già presa @amalsaidov l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
CompressionType.of fails under the Turkish localeForse già presa @sharanggupta l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno
-
[rocketmq-client-python] TransactionMQProducer allocates an unused producer during initializationAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
[Bug] notifyMasterOnline aborts the long-polling wake-up with a NullPointerException when an arrival drains a bucket firstForse già presa @iloveeyjafjalla l’ha presa 29 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
apache/rocketmq#11441 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
[Enhancement] FilterFactory duplicate-registration and unregister semantics lack testsForse già presa @chennaji9 l’ha presa 34 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
apache/rocketmq#11340 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di apache/rocketmq
Issue simili
-
bug emitter:client:csharp
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
microsoft/typespec#12572 · 1 commento · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
GCC 15.2: -Wcast-qual warning - cast discards const qualifier from pointer target type (H5trace.c)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
I maintainer di solito rispondono entro 1 giorno
-
needs-area-label
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 2 giorni
-
area/ai area/backend component/zeebe kind/task
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
spAnser/reacharound#38 ·