zhaohai666 opened a new pull request, #4220:
URL: https://github.com/apache/rocketmq-dashboard/pull/4220
# feat(studio): serve LiteTopic from the broker lite admin API
## Problem
The dashboard ships a complete ~900-line LiteTopic UI, but the backend
`LiteTopicService` is a stub: every endpoint returns `501` and
`getCapability()` reports `supported=false`. From a user's perspective the
feature is a shell — the page renders, nothing behind it works. Real LiteTopic
data (parent topics, TTL, sessions, quota, backlog) lives in the broker's lite
admin APIs and was never wired up.
## Solution
This PR replaces the stub with a real provider behind the existing SPI
pattern (`InstanceProvider` / `MetadataProvider` style), using only APIs that
are already available in the dashboard's declared dependency
`rocketmq-tools:5.5.0` — no new dependencies, no new ports, no new
configuration surface.
### New components
- **`LiteTopicProvider`** — new SPI interface (`isSupported()`,
`listLiteTopics`, `getSession`, `extendTTL`, `getQuota`) with a
backward-compatible default (501 `BusinessException`) so other vendors are
unaffected.
- **`RocketMQLiteTopicProvider`** (`@Primary` Apache implementation) — all
data comes from real broker RPCs on the master brokers discovered via
`examineBrokerClusterInfo`:
| API field | Real source |
|---|---|
| Parent topics + TTL | `getBrokerLiteInfo` `topicMeta` /
`getParentTopicInfo` (`lite.topic.expiration`, minutes) |
| Sessions (parent + group + client) | `getLiteClientInfo` (clientId →
`liteTopicSet`, `lastAccessTime`), `examineConsumerConnectionInfo` |
| Per-topic backlog / offsets | `getLiteGroupInfo` (`totalLagCount`, offset
wrappers) |
| Quota | `getBrokerLiteInfo`
(`currentLmqNum`/`maxLmqNum`/`liteSubscriptionCount`) + `getBrokerConfig`
(`maxLiteSubscriptionCount`, `minLiteTTl`) |
| TTL state | `lastAccessTime` + TTL → ACTIVE / EXPIRED, surfaced as ms in
the API contract (the broker stores minutes) |
- Scans are bounded (`MAX_LITE_TOPIC_SCAN=200`, `MAX_LITE_SESSION_SCAN=500`)
so a busy broker cannot stall the endpoint.
- Session identity (`parentTopic~group~clientId`) is validated on decode
(400 on malformed input).
- `LiteTopicService` keeps its existing request/response contract; the
frontend (`web/src/api/liteTopic.ts`) needs **no changes**.
## Notable broker protocol detail (found against a live 5.5.1 cluster)
`extendTTL` initially re-sent the message type through
`TopicConfig.setTopicMessageType(...)`. That writes a **bare** attribute key,
but the broker validates updates through `AttributeParser`, which only accepts
the `+key=value` change form — the call fails with `add/alter attribute format
is wrong: message.type`. Meanwhile `examineTopicConfig` reads attributes back
with bare keys, so the read and write protocols differ:
- Read: bare keys (`{message.type=LITE, lite.topic.expiration=2880}`),
getters work normally.
- Write: `+key=value` change entries; the broker **merges** them into the
stored attributes, and `message.type` is not re-alterable on an existing topic.
`extendTTL` therefore sends only `{"+lite.topic.expiration": "<minutes>"}`
and lets the broker merge it — verified end-to-end (see below).
## Runtime verification (real RocketMQ 5.5.1 cluster: NameServer + broker-a)
- `GET /api/liteTopic/capability` → `{"supported":true}` (real
`getBrokerLiteInfo` probe)
- `GET /api/liteTopic/list` → the LITE parent topic created via `mqadmin`
with its real TTL (1440 min → `averageTTL=86400000` ms)
- `GET /api/liteTopic/quota` → `maxTopicCount=20000`,
`maxSessionCount=100000` straight from broker lite info / config
- `POST /api/liteTopic/extendTTL` (1440 → 2880 min) → `200`, then re-read
via the lite admin API: `EXPIRATION_GETTER=2880`, `message.type=LITE` intact
## Testing
- New `RocketMQLiteTopicProviderTest` (13 tests): capability probe,
cross-master aggregation, pattern/namespace filtering, session resolution,
malformed session id, TTL ms→minutes conversion + clamp + non-LITE 404, quota
aggregation.
- `LiteTopicServiceTest` rewritten (10 tests): input validation (400s),
provider-model → VO mapping, unsupported-delegation.
- Full LiteTopic-related suite: **41/41 green**.
- Full server suite: no new failures (only the 2 pre-existing
`AuthCorsIntegrationTest` failures unrelated to this change).
## Checklist
- [x] No new Maven dependencies (uses the existing `rocketmq-tools:5.5.0`)
- [x] No frontend changes required (existing contract preserved)
- [x] Bounded scans; broker-unreachable yields 404/503 `BusinessException`s,
not fake data
- [x] Unit tests + live-cluster runtime verification
--
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]
