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 well-structured with clear class and method organization. It uses shallow nesting with only a simple if-else in tryComplete and no deeply nested blocks. The intent is clearly expressed through descriptive names, Javadoc, and trace logging. Code length is concise and avoids unnecessary verbosity. Action granularity is good, particularly in onComplete where distinct actions (filtering, logging, completing futures, running callback) are on separate lines. Reading flow is natural, with methods logically ordered: tryComplete checks conditions, onComplete handles completion, and onExpiration is documented as intentionally empty. The only minor drawback is the unused timeoutMs field after calling super(timeoutMs), but this is trivial and doesn't significantly impact readability.
Run 3
The code is highly readable with clear structure and intent. It follows logical organization with a class-level Javadoc, well-named fields, and methods that align with the DelayedOperation abstraction. Nesting is minimal, and each method performs a single conceptual action, keeping action granularity appropriate. The reading flow is natural: constructor initializes state, tryComplete checks completion conditions, onComplete handles finalization, and onExpiration documents its no-op behavior. Logging statements enhance clarity without excessive verbosity. Minor deductions: tryComplete could be slightly simplified, and the onComplete timeout message could be extracted into a constant. Overall, the code is concise, maintainable, and easy to understand.
Run 1
Code Structure: Fields, constructor, and lifecycle overrides are logically organized, with each method having a focused responsibility. Nesting: Control flow is shallow, with only one if/else block and straightforward stream operations. Clarity of intent: Descriptive names, documentation, and trace messages clearly explain completion checks, timeout handling, and callback execution. Code length: The implementation is concise, though the empty expiration method repeats its documentation and the else after a return is unnecessary. Action granularity: Most statements perform one clear action; the long exceptional-completion lambda combines iteration, exception construction, and completion, making it slightly harder to scan. Reading flow: The methods follow a natural lifecycle sequence, but long stream/lambda lines and tightly packed package/import declarations mildly reduce readability.
Run 2
Code Structure: Fields, constructor, and lifecycle methods are logically organized with clearly separated responsibilities. Nesting: Minimal nesting, limited to a straightforward if/else and simple lambdas. Clarity of intent: Descriptive names, documentation, and trace messages clearly explain completion and timeout behavior; the inherited lifecycle requires some external context. Code length: Concise overall, though the else after a return and duplicated onExpiration explanation are unnecessary. Action granularity: Statements generally perform one action each, but the long exceptional-completion lambda combines exception construction and future completion. Reading flow: Natural progression from initialization to completion checks, completion handling, and expiration; long stream and lambda lines slightly reduce scanability.
Run 3
Code Structure: Fields, constructor, and lifecycle methods are logically organized with clear responsibilities. Nesting: Only one shallow if/else; stream operations avoid nested loops. Clarity of intent: Descriptive names, logging, and documentation explain completion and timeout behavior, though understanding lifecycle ordering requires knowledge of DelayedOperation. 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; the long exceptional-completion lambda combines exception construction and completion but remains understandable. Reading flow: Natural progression from initialization to completion checks and cleanup. Long stream/lambda lines and tightly grouped imports slightly reduce scanability.