beautyarbutin opened a new issue, #11220:
URL: https://github.com/apache/rocketmq/issues/11220
### Before Creating the Bug Report
- [x] I found a bug, not just asking a question, which should be created in
GitHub Issues.
- [x] I searched open and closed Issues and pull requests for
`reviveQueueNum`, runtime config updates, revive queue resizing, and
`UPDATE_BROKER_CONFIG`; no equivalent report or fix was found.
- [x] I confirmed that this bug belongs to Apache RocketMQ.
### Runtime platform environment
Windows 11 host, reproduced deterministically in the repository's Maven test
environment using Eclipse Temurin JDK 8 in Docker. No live cluster is required.
### RocketMQ version
Branch: `develop`
Commit: `78b96bc5e21216cd7896efae08f90c5cde4cae53`
Version: 5.5.1-SNAPSHOT
### JDK Version
Eclipse Temurin 8, Maven 3.9.11.
### Describe the Bug
`reviveQueueNum` is accepted by the runtime `UPDATE_BROKER_CONFIG` endpoint
even though the POP revive topology is fixed when broker processors are
constructed.
`AckMessageProcessor` allocates its `PopReviveService[]` once from the
startup value, and the revive system topic is initialized with that queue
count. In contrast, `PopMessageProcessor`, `PeekMessageProcessor`, and the KV
POP path read `BrokerConfig.getReviveQueueNum()` for each request when
selecting a revive queue.
After a hot update, these structures disagree:
- Increasing the value lets new POP requests select queue IDs that have no
corresponding startup-created revive service and may not exist in the original
revive topic topology.
- Setting it to zero makes the request paths evaluate modulo zero and throw
`ArithmeticException`.
`reviveQueueNum` is not in `AdminBrokerProcessor`'s config blacklist, so the
update currently returns `SUCCESS` and mutates the live `BrokerConfig`.
### Steps to Reproduce
A focused regression test invokes the real broker config update path:
1. Construct `AdminBrokerProcessor` with the default `reviveQueueNum=8`.
2. Send an `UPDATE_BROKER_CONFIG` request containing `reviveQueueNum=9`.
3. Observe that the response code is `SUCCESS` and the live config changes
from 8 to 9, while `AckMessageProcessor` and the revive topic are not rebuilt.
Red-test output on unmodified `develop`:
```text
Broker receive request to update config, caller address=127.0.0.1:12345
updateBrokerConfig, new config: [{reviveQueueNum=9}]
Replace, key: reviveQueueNum, value: 8 -> 9
expected: NO_PERMISSION (16)
but was: SUCCESS (0)
```
Command:
```bash
mvn -B -ntp -pl broker -am \
-DskipITs \
-Dtest=AdminBrokerProcessorTest#testUpdateBrokerConfigRejectsReviveQueueNum \
-Dsurefire.failIfNoSpecifiedTests=false \
-Dspotbugs.skip=true test
```
### What Did You Expect to See?
`reviveQueueNum` should be treated as a restart-only lifecycle
configuration. Runtime updates should be rejected with `NO_PERMISSION`, leaving
the active value unchanged.
A non-positive startup value should also be rejected before POP processors
use it.
### What Did You See Instead?
The runtime update succeeds and mutates only the configuration value,
leaving startup-created revive services and queue topology inconsistent with
request-time queue selection.
### Additional Context
Affected paths include:
- `AckMessageProcessor` constructor: fixed-size `PopReviveService[]`
- `TopicConfigManager`: revive topic queue count initialized from the
startup value
- `PopMessageProcessor`, `PeekMessageProcessor`, and `PopConsumerService`:
request-time modulo using the current config value
- `AdminBrokerProcessor`: runtime update accepts the property because it is
absent from the blacklist
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
