zhaohai666 opened a new pull request, #4062:
URL: https://github.com/apache/rocketmq-dashboard/pull/4062
# feat(rip2): surface gRPC SDK clients in the console client view via the
proxy admin surface
## Motivation
gRPC SDK clients (e.g. `rocketmq-client-java` 5.0.x) never register with the
broker's
remoting admin, so the console's client view — which is backed by
`MQAdminExt`
(broker remoting) — cannot see them at all. With a 5.0 gRPC producer + push
consumer
running against a proxy, `/api/clients` only reported the Remoting-protocol
system
clients (`CLIENT_INNER_PRODUCER`, `CID_DefaultHeartBeatSyncerTopic`); the
real
application clients were invisible.
A proxy that implements the RIP-2 admin surface (upstream `Admin` service
from
rocketmq-apis 2.2.0, served on a dedicated admin gRPC port, default **8083**
— see
`feat/rip2-proxy-admin` in zhaohai666/rocketmq) already knows its gRPC
clients.
This branch teaches the console to merge that view in.
## Changes
- **`cluster/proxy/admin/Rip2ProxyAdminClient.java` (new)**
Blocking gRPC admin client for the upstream `Admin` contract:
`listSubscription` (group discovery) → `listConsumerConnection` per group.
3s per-RPC deadline; every failure degrades safely — when no admin endpoint
answers, the result is empty and the remoting view stays authoritative.
Endpoints come from `studio.rocketmq.proxy-admin-addresses` (env
`STUDIO_ROCKETMQ_PROXY_ADMIN_ADDRESSES`), or are derived from registered
proxy
hosts + `studio.rocketmq.proxy-admin-port` (default 8083).
- **`cluster/client/ClientService.java`**
Merges the gRPC consumers into the client view with `protocol=gRPC`, the
real
SDK version, language and address; deduplicates by `clientId` (remoting
entries
win). Skipped entirely when `type=Producer` (the upstream admin contract
has no
producer-connection list RPC).
- **`cluster/proxy/ProxyAddressService.java`**
Exposes `knownProxyAddresses()` so the admin client can derive candidate
admin endpoints from registered proxy addresses.
- **`server/pom.xml` / `application.yml`**
Adds `rocketmq-proto 2.2.0` + `grpc 1.59.1` (pinned via `grpc-bom`; the
offline
repository only has pom-only grpc 1.45 transitive poms, plus availability
pins for
guava / protobuf). New config keys under `studio.rocketmq`.
## Verification (end-to-end, real runtime)
mq side: `zhaohai666/rocketmq@feat/rip2-proxy-admin` (proxy data 8081 /
RIP-2 admin
8083); console: this branch, freshly built and restarted; client:
`rocketmq-client-java`
5.0.7 gRPC producer + push consumer.
```
GET /api/clients?namesrvAddr=127.0.0.1:9876&clusterId=DefaultCluster
Producer | Remoting | CLIENT_INNER_PRODUCER | ver V5_5_0
Consumer | Remoting | CID_DefaultHeartBeatSyncerTopic | ver V5_5_0
Consumer | gRPC | rip2e2e_grp | ver 5.0.7 ←
invisible before this change
Consumer | gRPC | rip2e2e_grp | ver 5.0.7 ←
invisible before this change
```
- Degradation: killing the keep-alive client / stopping the admin endpoint
drops
the view back to the remoting data with no 5xx.
- No mq-side changes required; the RIP-2 admin surface was exercised
read-only
(`listSubscription`, `listConsumerConnection`) plus the full 16-RPC probe
suite
(14/16 verified green with real data).
- `mvn -o test`: 2032/2035 pass. The 3 failures (`AuthCorsIntegrationTest`
×2,
`AliyunInstanceProviderTest` ×1) reproduce on a clean `rocketmq-studio`
baseline
worktree and are pre-existing upstream issues, unrelated to this change.
## Out of scope / notes
- Producer visibility over the admin surface: the upstream `Admin` contract
has no
producer-connection list RPC (documented boundary of the RIP-2 contract);
only
consumer connections are merged.
- Pre-existing upstream issue (not addressed here, suggest a separate PR):
the dev
profile configures an H2 datasource but `h2` is test-scoped, so the boot
jar
cannot start with `--spring.profiles.active=dev` unless the driver is
supplied
externally.
--
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]
