RockteMQ-AI commented on issue #10622: URL: https://github.com/apache/rocketmq/issues/10622#issuecomment-5002519825
**Issue Evaluation** Category: `type/enhancement` | Status: **Evaluated — Feasible** **Feasibility:** Feasible **Scope:** Single file (`LiteEventDispatcher.java`), ~4 lines changed **Compatibility:** No breaking changes ### Analysis The issue is valid. `BrokerController.consumerOffsetManager` is `protected` (non-final) with a public setter, and RocketMQ itself swaps the implementation at startup depending on storage mode. If that swap happens after `LiteEventDispatcher` is constructed, the dispatcher silently queries the stale instance. **Code evidence:** - Field: `LiteEventDispatcher.java:66` — `private final ConsumerOffsetManager consumerOffsetManager;` - Assignment: `LiteEventDispatcher.java:81` — cached from `brokerController.getConsumerOffsetManager()` - Usages: lines 233 and 277 — `consumerOffsetManager.queryOffset(...)` - `BrokerController.getConsumerOffsetManager()` exists at `BrokerController.java:1438` **Thread safety:** No concern — `getConsumerOffsetManager()` is a plain field read, identical to existing concurrent usage patterns. **Performance:** Negligible — replacing a direct field read with a one-hop method call carries no measurable overhead. **Note:** `LiteEventDispatcherTest.java` may need a one-line mock adjustment if it injects `consumerOffsetManager` via reflection rather than mocking `brokerController.getConsumerOffsetManager()`. ### Recommendation This is a minimal, low-risk change that directly fixes a real extensibility gap. A PR is welcome. --- *Automated evaluation by * -- 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]
