[studio] feat: expose gRPC client connection diagnostics in proxy GrpcChannelManager

[btlqql]

[studio] feat: expose gRPC client connection diagnostics in proxy GrpcChannelManager

Relates to #10600 (RocketMQ Studio: AI-Native Management Platform — Track 2: Proxy Admin management capability upgrade).

Background

GrpcChannelManager is the proxy-side source of truth for connected gRPC
clients (clientIdChannelMap) and for pending relay response futures
(resultNonceFutureMap). Until now it exposed no way to observe either,
which makes client connection management and runtime diagnosis impossible for
the Studio management platform and for admin/diagnostic tooling — the exact
capabilities called out by Track 2 of issue #10600 ("client connection
management and runtime diagnostic capabilities").

What this PR does

Adds three read-only, purely additive diagnostic methods to
org.apache.rocketmq.proxy.grpc.v2.channel.GrpcChannelManager:

Method	Purpose
getChannelCount()	Number of active gRPC client channels
getActiveClientIdSet()	Unmodifiable snapshot of connected client ids
getPendingResponseFutureCount()	Number of pending relay response futures

These methods do not alter any gRPC/proto API or protocol contract, so they
respect the Track 2 guideline that protocol/interface changes must be discussed
in an issue first. They are the foundation on which the Studio platform and
admin tooling can build standardized client-connection observation.

Why no protocol change here

Issue #10600 explicitly requires that Track 2 protocol/admin interface changes
be discussed and reach community consensus before code is submitted. This PR
intentionally avoids touching the proxy admin gRPC contract; it only opens up
read-only access to existing in-memory state so it can be consumed later by the
standardized admin layer once that design is agreed upon.

Tests

Adds GrpcChannelManagerTest (extends InitConfigTest, JUnit 4 + Mockito),
mirroring the existing GrpcClientChannelTest, covering:

• Channel create / get / remove and getChannelCount tracking
• Idempotent channel creation (same client id keeps a single channel)
• getActiveClientIdSet() returns an unmodifiable snapshot (independent of
  later channel removal)
• getPendingResponseFutureCount() accounting through
  addResponseFuture / getAndRemoveResponseFuture
• Proper shutdown of the internal scheduled executor in @After

Self-check

• Title is prefixed with [studio]
• Change is limited to a single cohesive concern (2 files)
• No gRPC/proto API or protocol contract is modified (Track 2 discuss-first rule respected)
• Unit tests added for the new behavior

[RockteMQ-AI]

Review by github-manager-bot

Summary

Adds three read-only diagnostic methods to GrpcChannelManager (getChannelCount, getActiveClientIdSet, getPendingResponseFutureCount) to support the RocketMQ Studio Track 2 client connection observability goal. Purely additive, no protocol changes.

Findings

• [Info] GrpcChannelManager.java:83 — getActiveClientIdSet() correctly creates a defensive copy via new HashSet<>(keySet()) before wrapping in unmodifiableSet. Thread-safe snapshot for diagnostic use.
• [Info] GrpcChannelManager.java:77,87 — .size() on ConcurrentHashMap returns a weakly-consistent count, which is appropriate for diagnostics (no locking overhead).
• [Info] GrpcChannelManagerTest.java — Good test coverage: idempotent creation, snapshot independence, unmodifiable enforcement (UnsupportedOperationException), and future accounting. Tests follow existing patterns (InitConfigTest, JUnit 4 + Mockito).

Suggestions

• [Info] Consider adding brief Javadoc to the three new public methods explaining their diagnostic purpose and thread-safety guarantees (weakly-consistent for counts, snapshot for client IDs). This helps future consumers understand the semantics without reading the implementation.

Verdict

Clean, well-tested, purely additive change. LGTM.

---

Automated review by github-manager-bot

[RockteMQ-AI]

Review by github-manager-bot

PR: [studio] feat: expose gRPC client connection diagnostics in proxy GrpcChannelManager
Verdict: ✅ Approved

Summary

Adds three diagnostic methods to GrpcChannelManager for monitoring active gRPC client connections:

• getChannelCount() — number of active client channels
• getActiveClientIdSet() — set of active client IDs (defensive copy, unmodifiable)
• getPendingResponseFutureCount() — number of pending response futures

Analysis

Correctness ✅

• getActiveClientIdSet() creates a defensive copy (new HashSet<>(clientIdChannelMap.keySet())) wrapped in Collections.unmodifiableSet() — prevents external modification of internal state. Good practice.
• All three methods are simple read-throughs to the underlying ConcurrentHashMap, thread-safe.

Performance ✅

• getActiveClientIdSet() copies the key set, which is O(n) in the number of active clients. Acceptable for diagnostics/monitoring use cases. If called frequently in hot paths, consider caching, but for monitoring this is fine.

Compatibility ✅

• Additive API — new public methods only, no existing behavior changed.

Tests ✅

• New test class GrpcChannelManagerTest with 164 lines covering:
  • Empty state diagnostics
  • Adding/removing channels and verifying counts
  • Verifying the returned client ID set is unmodifiable
  • Pending response future tracking
• Good test coverage for the new functionality.

Verdict

Clean, well-tested diagnostic addition. Useful for operational monitoring of proxy connections.