danny0405 commented on code in PR #20189: URL: https://github.com/apache/hudi/pull/20189#discussion_r4228513724
########## hudi-flink-datasource/hudi-flink/src/main/java/org/apache/hudi/sink/utils/FlinkRateLimiterFactory.java: ########## @@ -0,0 +1,92 @@ +/* + * 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.hudi.sink.utils; + +import org.apache.hudi.common.util.RateLimiter; +import org.apache.hudi.common.util.ValidationUtils; +import org.apache.hudi.common.util.VisibleForTesting; + +import java.util.concurrent.ScheduledExecutorService; +import java.util.concurrent.TimeUnit; + +/** + * Factory for distributing a job-wide write rate limit across Flink subtasks. + */ +public final class FlinkRateLimiterFactory { + + private FlinkRateLimiterFactory() { + } + + public static RateLimiter create(long totalRateLimit, int parallelism) { + RateLimitConfig rateLimitConfig = resolveRateLimit(totalRateLimit, parallelism); + return RateLimiter.create( + rateLimitConfig.getPermits(), rateLimitConfig.getReleasePeriod(), rateLimitConfig.getTimeUnit()); + } + + @VisibleForTesting + static RateLimiter create(long totalRateLimit, int parallelism, ScheduledExecutorService scheduler) { + RateLimitConfig rateLimitConfig = resolveRateLimit(totalRateLimit, parallelism); + return RateLimiter.create( + rateLimitConfig.getPermits(), rateLimitConfig.getReleasePeriod(), rateLimitConfig.getTimeUnit(), scheduler); + } + + static RateLimitConfig resolveRateLimit(long totalRateLimit, int parallelism) { + ValidationUtils.checkArgument(totalRateLimit > 0, "Total rate limit must be greater than zero"); + ValidationUtils.checkArgument(parallelism > 0, "Parallelism must be greater than zero"); + + if (totalRateLimit >= parallelism) { + long rateLimitPerSubtask = totalRateLimit / parallelism; + ValidationUtils.checkArgument(rateLimitPerSubtask <= Integer.MAX_VALUE, + "Rate limit per subtask exceeds the supported maximum"); + return new RateLimitConfig((int) rateLimitPerSubtask, 1, TimeUnit.SECONDS); + } + + long periodNanos = divideRoundingUp( + Math.multiplyExact(TimeUnit.SECONDS.toNanos(1), parallelism), totalRateLimit); + return new RateLimitConfig(1, periodNanos, TimeUnit.NANOSECONDS); Review Comment: Could we clarify in the PR description that this conservatively limits the long-run average, while allowing bursts? Each subtask starts with one available permit, so `write.rate.limit=1` with parallelism `4` lets four records through immediately, followed by four-second refill intervals. I reproduced the initial burst. This seems consistent with the existing bucket-style limiter, but the statement that the aggregate rate cannot exceed the configured value is too strong if read as a per-second guarantee. ########## hudi-common/src/main/java/org/apache/hudi/common/util/RateLimiter.java: ########## @@ -68,27 +94,67 @@ public boolean tryAcquire(int numPermits) { } public boolean acquire(int numOps) { + ValidationUtils.checkArgument(numOps > 0 && numOps <= maxPermits, + "Number of permits must be between one and the configured maximum"); + return acquireInternal(numOps); + } + + public boolean acquire() { + return acquireInternal(1); + } + + private boolean acquireInternal(int numOps) { try { - while (!semaphore.tryAcquire(numOps)) { + while (!stopped.get() && !semaphore.tryAcquire(numOps)) { Thread.sleep(WAIT_BEFORE_NEXT_ACQUIRE_PERMIT_IN_MS); } + ValidationUtils.checkState(!stopped.get(), "Rate limiter is stopped"); log.debug("acquire permits: {}, maxPermits: {}", numOps, maxPermits); } catch (InterruptedException e) { + Thread.currentThread().interrupt(); throw new RuntimeException("Unable to acquire permits", e); } return true; } - public void stop() { - scheduler.shutdownNow(); + public synchronized void stop() { + if (stopped.compareAndSet(false, true)) { Review Comment: Could we simplify the synchronization here? `stop()` and both scheduler-initialization methods already synchronize on the same instance, and `stop()` is the only writer of `stopped`. A `volatile boolean stopped` with an ordinary check/set under this monitor should be sufficient; CAS is redundant. Likewise, all accesses to `scheduler` are under that monitor, so its `volatile` modifier and the local `currentScheduler` snapshot are unnecessary. Keep `stopped` volatile because acquisition and `isStopped()` read it without taking the monitor. ########## hudi-common/src/test/java/org/apache/hudi/common/util/TestRatelimiter.java: ########## @@ -33,25 +44,91 @@ public class TestRatelimiter { @Test public void testRateLimiterWithNoThrottling() throws InterruptedException { RateLimiter limiter = RateLimiter.create(1000, TimeUnit.SECONDS); - long start = System.currentTimeMillis(); - assertEquals(true, limiter.tryAcquire(1000)); - // Sleep to represent some operation - Thread.sleep(500); - long end = System.currentTimeMillis(); - // With a large permit limit, there shouldn't be any throttling of operations - assertTrue((end - start) < TimeUnit.SECONDS.toMillis(2)); + try { + long start = System.currentTimeMillis(); + assertEquals(true, limiter.tryAcquire(1000)); + // Sleep to represent some operation + Thread.sleep(500); + long end = System.currentTimeMillis(); + // With a large permit limit, there shouldn't be any throttling of operations + assertTrue((end - start) < TimeUnit.SECONDS.toMillis(2)); + } finally { + limiter.stop(); + } } @Test public void testRateLimiterWithThrottling() throws InterruptedException { RateLimiter limiter = RateLimiter.create(100, TimeUnit.SECONDS); - long start = System.currentTimeMillis(); - assertEquals(true, limiter.tryAcquire(400)); - // Sleep to represent some operation - Thread.sleep(500); - long end = System.currentTimeMillis(); - // As size of operations is more than the maximum permits per second, - // whole execution should be greater than 1 second - assertTrue((end - start) >= TimeUnit.SECONDS.toMillis(2)); + try { + long start = System.currentTimeMillis(); + assertEquals(true, limiter.tryAcquire(400)); + // Sleep to represent some operation + Thread.sleep(500); + long end = System.currentTimeMillis(); + // As size of operations is more than the maximum permits per second, + // whole execution should be greater than 1 second + assertTrue((end - start) >= TimeUnit.SECONDS.toMillis(2)); + } finally { + limiter.stop(); + } + } + + @Test + public void testCustomReleasePeriod() { + ScheduledExecutorService scheduler = mock(ScheduledExecutorService.class); + + RateLimiter limiter = RateLimiter.create(1, 100, TimeUnit.MILLISECONDS, scheduler); + ArgumentCaptor<Runnable> refillTask = ArgumentCaptor.forClass(Runnable.class); + try { + verify(scheduler).scheduleAtFixedRate( + refillTask.capture(), eq(100L), eq(100L), eq(TimeUnit.MILLISECONDS)); + assertTrue(limiter.acquire()); + refillTask.getValue().run(); + assertTrue(limiter.acquire()); + } finally { + limiter.stop(); + } + verify(scheduler).shutdownNow(); + } + + @Test + public void testInvalidConfigurationIsRejected() { + assertThrows(IllegalArgumentException.class, () -> RateLimiter.create(0, TimeUnit.SECONDS)); + assertThrows(IllegalArgumentException.class, () -> RateLimiter.create(1, 0, TimeUnit.SECONDS)); + assertThrows(IllegalArgumentException.class, () -> RateLimiter.create(1, 1, null)); + } + + @Test + public void testInvalidAcquireRequestIsRejected() { + RateLimiter limiter = RateLimiter.create(1, 1, TimeUnit.DAYS); + try { + assertThrows(IllegalArgumentException.class, () -> limiter.acquire(0)); + assertThrows(IllegalArgumentException.class, () -> limiter.acquire(2)); + } finally { + limiter.stop(); + } + } + + @Test + public void testStopIsIdempotentAndUnblocksAcquire() throws Exception { + RateLimiter limiter = RateLimiter.create(1, 1, TimeUnit.DAYS); + ExecutorService executor = Executors.newSingleThreadExecutor(); + try { + assertTrue(limiter.acquire()); + Future<Boolean> blockedAcquire = executor.submit(() -> limiter.acquire()); + + limiter.stop(); Review Comment: Could we ensure the worker has actually reached the permit-waiting path before calling `stop()`? `submit()` does not guarantee that the task has started, so this test can pass by exercising only an acquisition that begins after shutdown. A deterministic signal from the waiting path would let the test distinguish those cases. I separately verified that the current implementation does unblock an already-waiting acquisition; this is a regression-coverage gap. -- 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]
