zjncs opened a new pull request, #3992: URL: https://github.com/apache/rocketmq-dashboard/pull/3992
### Motivation RocketMQ brokers publish the outbound (get-transferred) TPS under **different runtime-stats keys depending on the broker generation**: - **5.x** emits `getTransferredTps` (double r) — e.g. `StoreStatsService` in `release-5.3.1` - **4.x** keeps the historical `getTransferedTps` spelling (single r) — e.g. `StoreStatsService` in `release-4.9.4` The dashboard server only reads the 5.x key at all three consumption sites, so any cluster backed by 4.x brokers reports **tpsOut = 0** on the Dashboard overview and on the Cluster page, even while the broker is actively transferring messages. `tpsIn` (from `putTps`, same key on both generations) keeps working, which makes the failure look like "no outbound traffic" rather than a parsing bug. Affected read sites: - `RocketMQDashboardProvider#getDashboardData`: global `stats.tpsOut` and per-cluster `tpsOut` - `RocketMQClusterProvider`: per-broker `tpsOut` ### Modification Add a small per-class helper that resolves the outbound TPS entry by probing both spellings (5.x key first, 4.x legacy key as fallback), and use it at the three read sites. No behavior change for 5.x brokers; 4.x brokers now report their real outbound TPS. ### Verification Fail-before / pass-after regression tests (stub `fetchBrokerRuntimeStats` with only the legacy `getTransferedTps` key present): - `RocketMQClusterProviderTest#discoverClustersShouldReadLegacy4xBrokerOutboundTpsKey` — broker `tpsOut` was 0, now 30 - `RocketMQDashboardProviderTest#dashboardShouldReadLegacy4xBrokerOutboundTpsKey` — stats and cluster `tpsOut` were 0, now 5 Both full test classes pass: ``` Tests run: 16, Failures: 0, Errors: 0 -- in RocketMQClusterProviderTest Tests run: 30, Failures: 0, Errors: 0 -- in RocketMQDashboardProviderTest ``` Key-spelling evidence (upstream `StoreStatsService.java`): - release-4.9.4: `getTransferedTps` - release-5.3.1: `getTransferredTps` -- 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]
