RockteMQ-AI commented on issue #10569: URL: https://github.com/apache/rocketmq/issues/10569#issuecomment-4853647145
**Issue Evaluation** Category: `type/enhancement` | Status: **Evaluated** Thank you for the detailed feature request. Here is the assessment: **Feasibility:** Feasible — the proposed changes are well-scoped and follow existing patterns in the codebase. **Scope:** - **Broker**: Extending `NotificationProcessor` with `PopLiteLongPollingService` aligns with the existing long-polling architecture for lite consumers. - **Proxy**: Unifying `popMessage` with internal routing via `ProxyContext.isLiteConsumer()` reduces code duplication compared to maintaining separate API paths. - **Remoting**: Adding `isLiteConsumer` and `clientId` to `NotificationRequestHeader` is a minimal, backward-compatible protocol extension. **Compatibility:** The change is purely additive as described — existing Pop/Push/Simple consumers should remain unaffected. The `NotificationRequestHeader` extension with new fields is safe for wire compatibility as long as older clients ignore unknown fields (standard protobuf/gRPC behavior). **Considerations:** 1. Are there any edge cases around `hasEvents(clientId)` when a client switches between lite and normal consumption modes? 2. Should the `LITE_SIMPLE_CONSUMER` registration in `ClientActivity` / `GrpcClientSettingsManager` include migration logic for rolling upgrades where some proxy instances may not yet recognize the new type? 3. Will corresponding changes be needed in `apache/rocketmq-clients` for the Simple Consumer SDK to use this server-side support? Overall, this is a well-structured proposal with clear component-level breakdown. --- *Automated evaluation by RockteMQ-AI* -- 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]
