anjy7 commented on code in PR #22669: URL: https://github.com/apache/kafka/pull/22669#discussion_r3583272062
########## raft/src/testFixtures/java/org/apache/kafka/raft/DrainableCounter.java: ########## @@ -0,0 +1,43 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.kafka.raft; + +import java.util.function.IntSupplier; + +/** + * Tracks a cumulative, monotonically increasing counter (e.g. the work counters on the raft mocks) as + * a drainable delta against a baseline. The baseline is snapshotted at construction, and + * {@link #drainDelta()} returns the increase since construction or the previous drain, consuming it so + * nothing is counted twice. Draining with the result ignored therefore re-baselines the counter, e.g. + * to exclude setup work from the next measurement. + */ +final class DrainableCounter { + private final IntSupplier source; + private int baseline; + + DrainableCounter(IntSupplier source) { + this.source = source; + this.baseline = source.getAsInt(); + } + + int drainDelta() { Review Comment: A "drain interval" = the time between two `drainDelta()` calls = one `@Benchmark` invocation (it's called at the end of each, in `collectDeltasAndDrainRPCs`). For it to reach even 2³¹ (approx 2.1 billion) in one invocation, that single benchmark call would have to do 2 billion flushes, which is realistically not possible. Looking at the current tests, these numbers are usually single digit. And the reasoning behind having the counters in `KRaftBenchmarkingCounters` as long is that these variables hold/accumulate the per-op work across all invocations within a measurement iteration (millions of them under AverageTime), then reset each iteration. long gives ample headroom so that per-iteration sum can't overflow. This question also makes me think that the overflow test case for `DrainableCounter` is unnecessary since it tests an overflow which would never realistically happen. I think we should remove it. What do you think? -- 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]
