Before Creating the Bug Report
Runtime platform environment
All
RocketMQ version
develop
JDK Version
All
Describe the Bug
In rmq.broker.logback.xml, the filter appender is mistakenly named RocketmqRebalanceLockSiftingAppender, causing filter and rebalance lock logs to be routed incorrectly.
Steps to Reproduce
Start a broker using rmq.broker.logback.xml. Start a clustering DefaultMQPushConsumer with MessageListenerOrderly and a new consumer group, then check the queue lock logs.
What Did You Expect to See?
Rebalance lock logs in lock.log.
What Did You See Instead?
Rebalance lock logs appear in filter.log.
Additional Context
No response
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
All
RocketMQ version
develop
JDK Version
All
Describe the Bug
In
rmq.broker.logback.xml, the filter appender is mistakenly namedRocketmqRebalanceLockSiftingAppender, causing filter and rebalance lock logs to be routed incorrectly.Steps to Reproduce
Start a broker using
rmq.broker.logback.xml. Start a clusteringDefaultMQPushConsumerwithMessageListenerOrderlyand a new consumer group, then check the queue lock logs.What Did You Expect to See?
Rebalance lock logs in
lock.log.What Did You See Instead?
Rebalance lock logs appear in
filter.log.Additional Context
No response