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 is well-structured with clear separation of concerns across methods. Nesting is minimal, using stream operations to avoid deep indentation. Intent is clearly documented with Javadoc and in-method logs that explain state transitions. Code length is appropriate — no excessive verbosity. Action granularity is mostly one action per line, though some stream pipelines condense logic but remain readable. Reading flow is natural: constructor, tryComplete, onComplete, onExpiration follow logical lifecycle order. Minor deductions: the repeated `futures.stream().filter(...)` pattern could be extracted for reuse, and `onExpiration()` contains only a redundant comment, but these do not significantly harm readability.
Run 2
The code is highly readable with clear structure and intent. The class has a single responsibility and is well-organized with logical method ordering. Nesting is minimal - only one level inside methods. Each method has a clear purpose reflected in its name and Javadoc. Code length is appropriate without unnecessary verbosity. Action granularity is good, though the stream operations in tryComplete() and onComplete() combine multiple actions per line. The reading flow is natural: constructor, then tryComplete, onComplete, onExpiration. Logging statements enhance clarity. Minor deductions: the onExpiration() method is redundant (could be omitted entirely), and the stream filter operations compress logic that could be slightly more explicit. The timeoutMs field duplicates the parent class's timeout value, which is a minor design redundancy.
Run 3
The code is highly readable with a clear, logical structure. Each class is well-documented with purpose, and methods are concise with single responsibilities. Nesting is minimal, with only one level in the stream operations. Intent is evident from method names and comments, making the purpose of each component clear. Code length is appropriate — no unnecessary verbosity. Action granularity is well-maintained, with each statement focusing on a single logical step. Reading flow is natural: imports, class documentation, fields, constructor, then overridden methods in logical order. The only minor deductions are due to slightly repetitive logging and the empty onExpiration method, which could be simplified or omitted with a note in the base class, but these do not significantly impact overall readability.
Run 1
Code Structure: Fields, constructor, and lifecycle methods are logically organized with clear responsibilities. Nesting: Minimal nesting; only a simple if/else appears, while stream operations remain straightforward. Clarity of intent: Descriptive names and documentation explain completion, timeout handling, and callback execution; understanding lifecycle ordering requires some superclass context. Code length: Concise overall, though the empty expiration method repeats its documentation and the else after a return is unnecessary. Action granularity: Statements generally perform one action each, but the long lambda combines exception construction and future completion, making that line denser. Reading flow: Natural progression from initialization to completion checks and finalization; long stream and timeout lines slightly hinder scanning.
Run 2
Code Structure: Fields, constructor, and lifecycle methods are logically organized with clear responsibilities. Nesting: Only one shallow if/else block; stream operations avoid nested loops. Clarity of intent: Descriptive names, documentation, and logging explain completion and timeout behavior, though lifecycle ordering depends on the superclass. Code length: Concise overall, with minor redundancy in the else after a return and duplicated documentation for onExpiration. Action granularity: Statements generally perform one action each; the long exceptional-completion lambda combines filtering-related context, exception creation, and completion in a visually dense line. Reading flow: Natural progression from initialization to completion checks and cleanup, slightly weakened by long lines and the lack of separation between package and import groups.
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 the superclass lifecycle must be understood externally. Code length: Compact overall, with minor redundancy in the empty expiration method's documentation and an unnecessary else after a return. Action granularity: Statements generally perform one clear action; the long exceptional-completion lambda combines exception construction and completion but remains understandable. Reading flow: Natural progression from initialization to completion checks, completion handling, and expiration. Long stream/lambda lines and tightly packed imports slightly reduce scanability.