RockteMQ-AI commented on issue #10601:
URL: https://github.com/apache/rocketmq/issues/10601#issuecomment-4915073843

   **Issue Evaluation**
   
   Category: `type/enhancement` | Status: **Evaluated**
   
   Thank you for this well-structured RIP. The motivation is solid — the 
dashboard issues you reference (#381, #380, #402) confirm a real gap in gRPC 
client observability since 5.0.
   
   **Codebase Alignment**
   
   The proposed data sources already exist in the Proxy:
   - `GrpcChannelManager.clientIdChannelMap` holds the active client → channel 
mapping
   - `GrpcClientSettingsManager` manages negotiated settings per client
   - `HeartbeatSyncer` tracks heartbeat state
   
   So the foundational state is available; the gap is indeed the lack of an 
admin API surface to expose it.
   
   **Feedback on Design Decisions**
   
   **D1 (Service placement):** Option B (dedicated `ProxyAdminService`) is 
preferable for long-term extensibility. The Admin API surface will likely grow 
beyond client queries (connection management, diagnostic tools, etc.). A 
dedicated service avoids bloating the messaging `Admin` service and keeps the 
conceptual boundary clean. The "extra service" cost is minimal — one new 
service definition in `rocketmq-apis`.
   
   **D2 (Authorization):** The `proxy.admin.client` resource type with 
`LIST`/`GET` actions is a clean approach. The kill switch (`proxyAdminEnable`) 
is a good safety net for clusters that do not need admin exposure.
   
   **D3 (Local view):** Pragmatic for v1. One suggestion: consider adding a 
`proxy_group_id` field to the response so consumers can correlate local views 
across proxies without needing external configuration.
   
   **D4 (Cursor-based pagination):** Correct choice. Client connections are 
dynamic; offset-based pagination would be unreliable here.
   
   **Feasibility:** Feasible — the underlying data structures exist, and the 
proposed proto definitions are clean.
   
   **Scope:** Primarily `proxy/` module + `rocketmq-apis` for proto 
definitions. Minimal impact on other modules.
   
   **Compatibility:** No breaking changes — purely additive API surface.
   
   This RIP is ready for community discussion and consensus on D1 before 
implementation begins.
   
   ---
   *Automated evaluation by github-manager-bot*


-- 
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]

Reply via email to