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 timeout, List<CompletableFuture<T>> fut, Runnable response) {
super(timeout);
this.timeoutMs = timeout;
this.futures = fut;
this.responseCallback = response;
}
/**
* The operation can be completed if all the futures have completed successfully
* or failed with exceptions.
*/
@Override
public boolean try2() {
log.trace("Trying to complete operation for {} futures", futures.size());
long pen = futures.stream().filter(future -> !future.isDone()).count();
if (pen == 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", pen);
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 on() {
List<CompletableFuture<T>> pending = futures.stream().filter(future -> !future.isDone()).toList();
log.trace("Completing operation for {} futures, expired {}", futures.size(), pending.size());
pending.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 on2() {
// This is invoked after onComplete(), so no actions required.
}
}
Run 1
The code is generally well-structured and readable, but has several issues. The method names 'try2()', 'on()', and 'on2()' are ambiguous and don't clearly convey intent - better names like 'tryComplete()' or 'onComplete()' would improve clarity. Variable 'pen' is unclear and should be 'pendingCount'. The class has good documentation and logical organization. Nesting is minimal with only one level of conditional logic. The stream operations are concise but could be more readable with helper methods. Method length is appropriate. Reading flow is mostly natural, but the empty 'on2()' method with only a comment feels redundant. The action granularity is good with one action per line. Overall, the code is functional but the naming conventions significantly impact readability and intent clarity.
Run 2
The code is generally well-structured with clear class-level documentation, but suffers from several clarity issues. The method names `try2()`, `on()`, and `on2()` are ambiguous and don't convey their purpose—this significantly reduces readability since the intent requires reading method bodies. The variable name `pen` should be `pending` for clarity. The `try2()` method has straightforward logic but could be simplified with a single `allMatch()` call rather than filter/count. Action granularity is mostly good with one action per line, though the stream operations could be broken down. The nested stream operations add some complexity. The code shows good organization with clear separation of concerns, helpful logging, and reasonable documentation, but the unconventional method naming and abbreviated variable names are notable readability problems that require a reader to examine the code closely to understand functionality.
Run 3
The code demonstrates good structure with clear class-level Javadoc and method-level comments explaining intent. Imports are organized and the class extends a logical base. Nesting is mostly flat, using stream operations cleanly. Purpose is well-communicated through method names and comments. However, method names `try2()`, `on()`, and `on2()` are ambiguous—they don't clearly convey their roles. Variable names like `pen` and `fut` reduce clarity. Additionally, `timeoutMs` field duplicates parent state, adding minor redundancy. The code is concise and avoids unnecessary length. Action granularity is generally good, though stream pipelines combine multiple steps. Overall, the code is readable but would benefit from improved naming conventions for methods and variables to more clearly express intent.
Run 1
Code Structure: Fields, constructor, and lifecycle methods are logically organized with focused responsibilities. Nesting: Minimal nesting; only a simple conditional and straightforward lambdas. Clarity of intent: Comments and descriptive field names explain future completion and timeout handling, but method names try2, on, and on2 obscure lifecycle roles; fut, response, and pen are less descriptive. Comments referencing onComplete() do not match the visible method names. Code length: Generally concise, although the empty method repeats its documentation and the else after a return is unnecessary. Action granularity: Statements generally perform one action per line, but the lengthy completeExceptionally lambda combines timeout construction and completion, making it harder to scan. Reading flow: Constructor-to-completion ordering is natural, but cryptic method names, tightly packed imports, and long stream/lambda lines interrupt readability.
Run 2
Code Structure: Fields, constructor, and lifecycle methods are logically organized, with helpful documentation. Nesting: Minimal nesting; only a simple if/else and short lambdas. Clarity of intent: Future completion and timeout handling are understandable, but method names try2, on, and on2 are opaque, and pen, fut, and response are less descriptive than alternatives. Comments referring to onComplete() do not clearly map to the shown methods. Code length: Compact overall, though the empty method repeats its documentation and the else could be omitted after the return. Action granularity: Statements generally perform one action each; the long exceptional-completion lambda combines several expressions and is harder to scan. Reading flow: The class proceeds naturally from initialization to completion checking and cleanup, but abbreviated names, tightly grouped imports, and long stream/lambda lines interrupt readability.
Run 3
Code Structure: Fields, constructor, and lifecycle methods are logically organized and responsibilities are separated. Nesting: Only one shallow conditional; stream operations avoid nested loops. Clarity of intent: Documentation and descriptive field names explain the purpose, but method names try2, on, and on2 and variables fut and pen are ambiguous. References to onComplete() do not clearly match the displayed method names. Code length: Compact overall, although the empty method repeats its documentation and the else after a return is unnecessary. Action granularity: Statements generally perform one action each, but the long exceptional-completion lambda combines iteration, exception construction, and completion on one line. Reading flow: The constructor-to-completion sequence is natural, but cryptic lifecycle names and long stream expressions interrupt readability.