DL1231 commented on PR #20152: URL: https://github.com/apache/kafka/pull/20152#issuecomment-3231129094
> @DL1231 I am sorry I still can't follow why we need new MetricConfig and can't do correct calculation in the method itself, https://github.com/apache/kafka/pull/20152#discussion_r2200852049? @apoorvmittal10 Simply considering the `timeUnit` in the `windowSize` might not be sufficient, because the `timeWindowMs` in `MetricConfig` affects multiple parts of the logic, such as https://github.com/apache/kafka/blob/7527a8bac088ac551a34c7ef2447588f70d8ec7e/clients/src/main/java/org/apache/kafka/common/metrics/stats/SampledStat.java#L148 If we only modify the logic of `windowSize`, consider the following scenario: 1. In `MetricConfig`, the default `timeWindowMs` is 30 seconds, and `DEFAULT_NUM_SAMPLES` = 2, meaning it can retain data for at most 60 seconds. 2. If rebalances occur twice—once at the 1st minute and again at the 59th minute—the expected value for rebalance-rate-per-hour should be 2. 3. At the 59th minute, when calculating the rebalance rate, since only 60 seconds of data can be retained, the rebalance count = 1. If we consider `timeUnit` in `windowSize`, the time window would become 1 hour. As a result, the calculated rebalance-rate-per-hour = rebalance count / window size = 1 / 1h = 1, which is not equal to 2. -- 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: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
