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

Abierto
  • ¿Algo no está bien?
#11,400 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@iloveeyjafjalla ya está trabajando en esto.

Desde el 13/10/2026.

  • #11401 de @iloveeyjafjalla — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
observability

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Java
Estrellas
22.7k
Forks
12k
Merge medio
3 d 18 h
PR fusionados (30 d)
17

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/rocketmq

Todos los issues de apache/rocketmq

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.