tju-yxq opened a new issue, #1437: URL: https://github.com/apache/rocketmq-dashboard/issues/1437
## Bug Report ### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Runtime platform environment OS: Ubuntu 20.04 / Any OS running RocketMQ Studio ### RocketMQ version branch: rocketmq-studio version: 5.3.2+ Git commit id: f727341 ### JDK Version OpenJDK 21 ### Describe the Bug Two providers parse the **same** RocketMQ broker TPS string but return **different values**, causing the cluster detail page and the dashboard overview to show inconsistent TPS numbers for the same broker at the same point in time. - **`RocketMQClusterProvider.parseFirstTpsValue()`** returns `parts[0]` as `int` (10-minute average) - **`RocketMQDashboardProvider.parseTps()`** returns `parts[1]` as `long` (1-minute average) The RocketMQ broker runtime stats format for `putTps` / `getTransferredTps` is a space-separated string like `"10.5 8.3 9.1"` representing 10min avg, 1min avg, and 10sec avg. The two providers pick different positions, so the cluster detail page shows a different TPS than the dashboard overview for the same broker. Additionally, `parseFirstTpsValue` returns `int` which can overflow for very high TPS values (> 2.1 billion), while `parseTps` returns `long`. ### Steps to Reproduce 1. Start a RocketMQ cluster with some message traffic. 2. Open the dashboard overview - note the TPS values. 3. Click into a cluster detail page - note the TPS values. 4. Compare: the two pages show different TPS for the same broker. ### What Did You Expect to See? Both pages should display the same TPS value using a consistent parsing strategy and return type. ### What Did You See Instead? Dashboard shows 1-minute average; cluster detail shows 10-minute average. ### Additional Context **Related**: #895 fixed a whitespace-splitting bug in `parseFirstTpsValue` but did not address the index inconsistency. **Affected files**: - `server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQClusterProvider.java` - `parseFirstTpsValue()` returns `parts[0]` as `int` - `server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQDashboardProvider.java` - `parseTps()` returns `parts[1]` as `long` **Fix**: Unify both to use `parts[1]` (1-minute average) with `long` return type, or extract a shared utility method. -- 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]
