Fixes #24846

Main Issue: #xyz

PIP: #xyz

Motivation

The test PublishRateLimiterOverconsumingTest.testOverconsumingTokensWithBrokerPublishRateLimiter was intermittently failing under concurrent + batching scenarios. Failures were caused by:

• Warm-up and window misalignment: the first effective “second” often spans partial time across two real seconds, producing a very low first bucket and a very high second bucket (e.g., 24 and 1212).
• Bursty traffic: multiple independent producers with batching flushes lead to token bursts that concentrate into a single second.
• Average rate computed from total elapsed time: when bursts make the overall processing time shorter, avg = totalMessages/timeSinceStart becomes artificially high (e.g., 750 vs 500) even though the rate limiter is fine.

These issues are the same class as addressed for Dispatch in PR #24012. The test needs to measure rate more robustly to avoid false negatives while still detecting real regressions.

org.apache.pulsar.broker.service.DispatchRateLimiterOverconsumingTest#testOverconsumingTokensWithBrokerDispatchRateLimiter

Modifications

This change makes the test resilient by aligning measurement and smoothing per-second variability, following the approach used for Dispatch in PR #24012:

• Align measurement start to the first received message:

  • Start counting only after the first message arrives (set startTimeNanos in the messageListener). This removes the initial misalignment in the first bucket.

• Use windowed average for “overall average”:

  • Compute the test’s “average rate” from the collected per-second windows (skip the first second and take up to durationSeconds windows), instead of using totalMessages/elapsedTime, which is sensitive to overall time shortening due to bursts.
  • Assertion: the window-based average must be within ±40% of the configured rate.

• Use adjacent 2-second averages for per-second stability:

  • For each pair of adjacent seconds (skipping the head and tail pairs), assert that the mean of the two is within ±55% of the configured rate. This compensates for a low bucket followed by a high bucket caused by bursts or warm-up misalignment.
  • If there are too few windows (< 4), fall back to a single-second check (skip head and tail) with a ±50% tolerance to avoid spurious failures.

• Make wait condition robust:

  • Wait for all messages to be consumed rather than requiring a particular number of windows. This avoids waiting on windows in fast runs.

• Include trailing partial window:

  • Add the last partial bucket (if any) to the snapshot to not silently drop the tail.

• Non-functional/logging:

  • Keep the 500 ms polling for the rate tracker but only emit a per-second rate on full-second boundaries using lastCalculatedSecond.
  • Additional comments and logs for clarity.

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository: Denovo1998#13