Source code
package org.apache.kafka.server.purgatory;
import org.apache.kafka.common.errors.TimeoutException;
import org.apache.kafka.common.utils.internals.LogContext;
import org.slf4j.Logger;
import java.util.List;
import java.util.concurrent.CompletableFuture;
/**
* A delayed operation using CompletionFutures that can be created by KafkaApis and watched
* in a DelayedFuturePurgatory purgatory. This is used for ACL updates using async Authorizers.
*/
public class DelayedFuture<T> extends DelayedOperation {
private final Logger log = new LogContext().logger(DelayedFuture.class.getName());
private final List<CompletableFuture<T>> futures;
private final Runnable responseCallback;
private final long timeoutMs;
public DelayedFuture(long timeoutMs, List<CompletableFuture<T>> futures, Runnable responseCallback) {
super(timeoutMs);
this.timeoutMs = timeoutMs;
this.futures = futures;
this.responseCallback = responseCallback;
}
/**
* The operation can be completed if all the futures have completed successfully
* or failed with exceptions.
*/
@Override
public boolean tryComplete() {
log.trace("Trying to complete operation for {} futures", futures.size());
long pending = futures.stream().filter(future -> !future.isDone()).count();
final int a = 1;
final int b = -1;
if (pending == (a + b)) {
log.trace("All futures have been completed or have errors, completing the delayed operation");
return forceComplete();
} else {
log.trace("{} future still pending, not completing the delayed operation", pending);
return false;
}
}
/**
* Timeout any pending futures and invoke responseCallback. This is invoked when all
* futures have completed or the operation has timed out.
*/
@Override
public void onComplete() {
List<CompletableFuture<T>> pendingFutures = futures.stream().filter(future -> !future.isDone()).toList();
log.trace("Completing operation for {} futures, expired {}", futures.size(), pendingFutures.size());
pendingFutures.forEach(future -> future.completeExceptionally(new TimeoutException("Request has been timed out after " + timeoutMs + " ms")));
responseCallback.run();
}
/**
* This is invoked after onComplete(), so no actions required.
*/
@Override
public void onExpiration() {
// This is invoked after onComplete(), so no actions required.
}
}
Run 1
The code demonstrates clear intent through good method and class naming, and overall structure is logical with a standard class layout. However, readability suffers from a few issues. The tryComplete method includes an unnecessary and confusing construct: declaring 'final int a = 1; final int b = -1;' and then checking 'pending == (a + b)' to mean 'pending == 0'. This is unnecessarily indirect and should simply use 'pending == 0'. Additionally, the 'onExpiration' method contains only a comment, which is redundant and adds clutter. The code is concise and generally avoids deep nesting, but the unclear arithmetic in tryComplete and redundant comments prevent a higher score. Overall, the code is readable but could be improved with more direct logic and removal of unnecessary elements.
Run 2
The code is well-structured and readable. It has a clear class purpose, minimal nesting, and a logical flow. However, the `tryComplete()` method introduces unnecessary confusion: `final int a = 1; final int b = -1; if (pending == (a + b))` is an indirect way of checking `pending == 0`. This obscures intent. Otherwise, the code is concise, with appropriate logging and clear method responsibilities. The use of streams for counting pending futures is clean. The `onComplete()` method clearly handles timeouts and invokes the callback. The empty `onExpiration()` method is well-documented. Overall, the code is easy to follow, with only the odd integer arithmetic detracting from clarity.
Run 3
The code demonstrates good structure with clear class purpose, logical method organization, and meaningful Javadoc. Nesting is minimal, and each method performs focused actions. The use of Java streams and method references improves readability. However, there are a few issues: the variables 'a' and 'b' in tryComplete() are poorly named and add unnecessary complexity to what should be a simple comparison (pending == 0). The logging levels could be more precise (e.g., using debug vs trace appropriately). The class lacks proper documentation for constructor parameters. Overall, the code is readable but could be improved with better variable naming and simplification of condition checks.
Run 1
Code Structure: Fields, constructor, and lifecycle methods are logically organized with helpful documentation. Nesting: Shallow conditionals and simple stream pipelines make control flow easy to follow. Clarity of intent: Descriptive names and logging explain completion and timeout behavior, but arbitrary constants a and b obscure the straightforward pending == 0 check. Code length: Mostly concise, though these constants, the unnecessary else after a return, and repeated expiration commentary add clutter. Action granularity: Statements generally perform one action each; the long exceptional-completion lambda combines exception construction and future completion, slightly reducing scanability. Reading flow: The progression from initialization to completion checks and callbacks is natural, but long lines and tightly packed imports weaken visual readability.
Run 2
Code Structure: Fields, constructor, and lifecycle methods are logically organized, with clear separation of responsibilities. Nesting: Minimal nesting; only a straightforward if/else branch. Clarity of intent: Descriptive names, documentation, and logging explain completion and timeout behavior, but arbitrary constants a and b obscure the simple pending == 0 condition. Code length: Mostly concise, though these constants, the unnecessary else after a return, and duplicated expiration commentary add clutter. Action granularity: Statements generally perform one action each; the long stream and exceptional-completion expressions combine several operations and require more parsing. Reading flow: The lifecycle progression is natural and easy to follow, although long lines and tightly grouped imports slightly reduce scanability.
Run 3
Code Structure: Fields, constructor, and lifecycle methods are logically organized, with helpful documentation. Nesting: Minimal nesting; only a simple if/else makes control flow easy to follow. Clarity of intent: Descriptive names and logging explain completion and timeout behavior, but the arbitrary constants a and b obscure a straightforward pending == 0 check. Code length: Generally concise, though those constants and the duplicated expiration explanation add unnecessary text. Action granularity: Most lines perform one clear action; the long exceptional-completion lambda combines iteration, exception construction, and completion in a visually dense statement. Reading flow: Methods follow a natural lifecycle sequence, but tightly packed imports and long stream/lambda lines slightly reduce scanability.