Repository navigation
Conversation
Signed-off-by: zhang hongyuan <100520587+Metastarx@users.noreply.github.com>
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #11451 +/- ##
=============================================
+ Coverage 49.76% 50.04% +0.28%
- Complexity 14377 14567 +190
=============================================
Files 1390 1394 +4
Lines 103262 103557 +295
Branches 13504 13548 +44
=============================================
+ Hits 51392 51830 +438
+ Misses 45681 45501 -180
- Partials 6189 6226 +37 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
RockteMQ-AI
left a comment
There was a problem hiding this comment.
Suggestions
- Remove
broker/null/config/delayOffset.json— likely an accidental commit. - Add a server-side cap on
maxCountin the processor (e.g.,Math.min(maxCount, 10000)). - Wrap
Integer.parseIntin the SubCommand with a user-friendly error message.
Overall
The implementation is clean, follows existing patterns for lite topic admin commands, and has good test coverage. The protocol design (reusing LiteTopicRequestHeader, adding hasMore for pagination) is sound. Addressing the accidental file and the two warnings above would make this ready to merge.
Automated review by github-manager-bot
Signed-off-by: zhang hongyuan <100520587+Metastarx@users.noreply.github.com>
|
Addressed in bb28e1b. |
| ); | ||
| } | ||
| if (responseBody.isHasMore()) { | ||
| System.out.printf("[%s] returned %d lite topics; increase -m to list more.%n", |
There was a problem hiding this comment.
Could we distinguish the broker's hard limit from the requested limit in this hint? Once 10,000 matching lite topics are returned, increasing -m cannot list any more because the broker clamps it to MAX_RETURN_COUNT; suggesting a narrower prefix would give operators an actionable next step.
Signed-off-by: zhang hongyuan <100520587+Metastarx@users.noreply.github.com>
|
Addressed in d0f94fa. |
Which Issue(s) This PR Fixes
Brief Description
RocketMQ currently exposes an aggregate lite topic count plus single-topic and single-client lookups, but there is no broker-side way to enumerate the dynamically created lite topics under a parent topic. This change adds a GET_LITE_TOPIC_LIST request with a required parent topic, an optional name prefix, and a bounded maxCount, and the broker returns each lite topic's offsets, last update time, subscriber count, and sharding ownership together with a hasMore truncation flag. The new client, admin, and DefaultMQAdminExt methods are wired through a getLiteTopicList mqadmin command (also available as listLiteTopic) that prints one table row per broker, and the LMQ guide documents the command and sample output.
How Did You Test This Change?
mvn test -pl broker,client,remoting,tools- passed (Tests run: 172, Failures: 0, Errors: 0, Skipped: 5)