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();
if (pending == 0) {
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 excellent readability through clear class and method naming, concise documentation, and logical organization. The structure follows a natural flow: constructor, then override methods in order of lifecycle. Each method has a single responsibility, keeping nesting minimal—the deepest nesting is only one level within stream filters. Intent is clearly communicated through javadoc comments and descriptive log messages. Code length is appropriate, avoiding unnecessary verbosity while maintaining clarity. Action granularity is well-balanced; complex operations like the stream filter are self-contained on single lines, while method calls are properly indented. The reading flow is natural and intuitive, with consistent formatting and purposeful comments that explain the 'why' rather than the 'what'. The only minor deduction is the slightly verbose log statements that could be more concise, but overall this is highly maintainable code.
Run 2
The code is well-structured with a clear class hierarchy and consistent logging. It uses flat nesting, with only one conditional block in tryComplete() and no deep indentation. Intent is explicit through method names and Javadoc comments, making the purpose of each method immediately clear. The code is concise without unnecessary verbosity. Each logical action (logging, filtering, completing) is on its own line, improving readability. Reading flow is natural: constructor, completion logic, then timeout handling. Minor deductions: onExpiration() is empty (though documented), and the log message in onComplete() could be slightly clearer about what 'expired' means. Overall, very readable code that follows good practices for maintainability.
Run 3
The code is well-structured with clear class-level documentation and focused methods. Each method has a single responsibility, and nesting is minimal (only simple stream operations). Variable and method names are descriptive, making intent obvious. The code is concise without unnecessary boilerplate, and action granularity is appropriate—each line performs one logical operation. Logging statements aid debugging without cluttering the core logic. Minor improvements could include extracting the timeout message or simplifying stream operations, but overall, the code reads naturally and is highly maintainable.
Run 1
Code Structure: Fields, constructor, and lifecycle methods are logically organized, with each method handling a distinct responsibility. Nesting: Only a shallow if/else is used; stream operations avoid nested loops. Clarity of intent: Descriptive names, documentation, and logging clearly explain completion checks, timeout handling, and callback execution. Code length: The implementation is concise, though the empty expiration method repeats its explanation and the else could follow an early return instead. Action granularity: Statements generally perform one action each, but the exceptional-completion lambda combines iteration, exception construction, and completion in a long line. Reading flow: The sequence from initialization through completion checking and cleanup is natural. Minor drawbacks include long stream expressions and limited visual separation around the package and imports.
Run 2
Code Structure: Fields, constructor, and lifecycle methods are logically organized with clear responsibilities. Nesting: Very shallow; only a simple if/else and short lambdas. Clarity of intent: Descriptive names, documentation, and logging explain completion and timeout handling, although lifecycle ordering depends on superclass behavior. Code length: Concise overall, with minor redundancy in the empty onExpiration method's documentation and an unnecessary else after a return. Action granularity: Statements generally perform one action each, though the long exceptional-completion lambda combines exception construction and future completion. Reading flow: Natural progression from initialization to completion checks and cleanup; long stream and lambda lines slightly reduce scanability.
Run 3
Code Structure: Fields, constructor, and lifecycle methods are logically organized, with focused responsibilities. Nesting: Only one shallow conditional; stream operations avoid nested loops. Clarity of intent: Descriptive names, documentation, and logging clearly explain completion and timeout behavior, though understanding lifecycle ordering requires knowledge of DelayedOperation. Code length: Concise overall, with minor redundancy in the else branch and repeated explanation of onExpiration. Action granularity: Statements generally perform one action each; the long exceptional-completion lambda combines exception construction and completion, slightly reducing scanability. Reading flow: Natural progression from initialization to completion checks and cleanup. Long stream/lambda lines and tightly grouped imports slightly detract from otherwise strong readability.