Source code
package org.apache.kafka.controller;
import org.apache.kafka.common.errors.ThrottlingQuotaExceededException;
import org.apache.kafka.common.message.RequestHeaderData;
import org.apache.kafka.common.security.auth.KafkaPrincipal;
import org.apache.kafka.common.utils.Time;
import org.apache.kafka.server.authorizer.AuthorizableRequestContext;
import java.util.OptionalLong;
import java.util.function.Consumer;
import static java.util.concurrent.TimeUnit.MILLISECONDS;
import static java.util.concurrent.TimeUnit.NANOSECONDS;
public class ControllerRequestContext {
public static OptionalLong request(
Time tim,
int milliseconds
) {
return OptionalLong.of(tim.nanoseconds() + NANOSECONDS.convert(milliseconds, MILLISECONDS));
}
private final KafkaPrincipal principal;
private final OptionalLong deadlineNs;
private final RequestHeaderData requestHeader;
private final Consumer<Integer> partitionChangeQuotaApplier;
public ControllerRequestContext(
RequestHeaderData request,
KafkaPrincipal pri,
OptionalLong deadline
) {
this(request, pri, deadline, __ -> { });
}
public ControllerRequestContext(
RequestHeaderData request2,
KafkaPrincipal pri2,
OptionalLong deadline2,
Consumer<Integer> partition
) {
this.requestHeader = request2;
this.principal = pri2;
this.deadlineNs = deadline2;
this.partitionChangeQuotaApplier = partition;
}
public ControllerRequestContext(
AuthorizableRequestContext request3,
OptionalLong deadline3
) {
this(request3, deadline3, __ -> { });
}
public ControllerRequestContext(
AuthorizableRequestContext request4,
OptionalLong deadline4,
Consumer<Integer> partition2
) {
this(
new RequestHeaderData()
.setRequestApiKey((short) request4.requestType())
.setRequestApiVersion((short) request4.requestVersion())
.setCorrelationId(request4.correlationId())
.setClientId(request4.clientId()),
request4.principal(),
deadline4,
partition2
);
}
public RequestHeaderData request2() {
return requestHeader;
}
public KafkaPrincipal pri() {
return principal;
}
public OptionalLong deadline() {
return deadlineNs;
}
/**
* Apply the partition change quota.
*
* @param requestedPartitionCount The value to apply.
* @throws ThrottlingQuotaExceededException If recording this value moves a metric beyond its configured
* maximum or minimum bound
*/
public void apply(int requested) {
partitionChangeQuotaApplier.accept(requested);
}
}
Run 1
The code has clear logical organization, with static utility, fields, constructors, and methods separated logically. Nesting is mostly flat, except for the builder chain in the constructor, which is acceptable. Clarity of intent is generally good, but variable names like 'pri2', 'request2', 'deadline2', and 'partition2' are unclear and reduce readability. Action granularity is mostly one action per line. Reading flow is natural. The code is concise, but the multiple constructors with similar names (request2, request3, request4) are confusing. The method 'request()' is static and public, but its purpose is not immediately obvious from its name. Overall, it is readable but could be improved with better naming.
Run 2
The code has clear purpose and reasonable organization, but readability is hampered by poor naming conventions, redundant constructors, and inconsistent parameter naming. The multiple constructors with parameters named `request2`, `pri2`, `deadline2`, etc. are confusing - suffixes like '2' provide no semantic meaning. The method names `request2()` and `pri()` are cryptic and misleading. The static helper `request()` is oddly placed and the parameter name `tim` is unnecessarily abbreviated. The constructor chaining creates unnecessary nesting at the object construction level, though the code itself isn't deeply nested. The code is concise but at the cost of clarity - abbreviated names and numbered suffixes force readers to track variable origins mentally. The quota applier logic and deadline calculation are straightforward, but the authorizable request conversion is dense. Overall, the code would benefit from descriptive naming and constructor consolidation.
Run 3
The code is generally readable but has several issues that reduce clarity. The structure is logical, and the class is reasonably organized with overloaded constructors, but variable naming (e.g., 'pri', 'tim', '__', 'partition', 'partition2') is cryptic and harms intent. The constructors are flat and not deeply nested, but the overloading and repetitive patterns make the flow slightly confusing. Action granularity is mostly one action per line, which is good, but the static factory method 'request' has a misleading name and sits among constructors. The code is concise but at the cost of clarity in naming and intent. The use of lambda no-op consumers is okay but could be clearer. Overall, it's understandable but could be significantly improved with better naming and a more intuitive constructor chain.
Run 1
Code Structure: Fields, constructor overloads, and accessors are logically grouped, and constructor delegation avoids duplication, though the static helper preceding fields slightly interrupts organization. Nesting: Very shallow, with no nested control flow. Clarity of intent: Descriptive field names help, but vague methods such as request(), request2(), pri(), and apply(), plus numbered parameters, obscure purpose. The Javadoc parameter name also differs from the actual parameter. Code length: Concise overall; multiline signatures add some vertical space without substantial complexity. Action granularity: Assignments and calls generally perform one action per line; the header-building chain is clearly formatted. Reading flow: Constructor delegation and straightforward accessors are easy to follow, but inconsistent naming and tightly packed imports reduce polish and require readers to infer meaning.
Run 2
Code Structure: Fields, constructor overloads, and accessors are logically organized, with constructor delegation avoiding duplication. Nesting: Almost entirely flat; the fluent header construction is easy to follow. Clarity of intent: Descriptive field names help, but names such as request(), request2(), pri(), tim, and numbered parameters obscure purpose. The apply() documentation refers to requestedPartitionCount rather than the actual parameter requested. Code length: Compact and largely justified, though multiline signatures add some visual bulk. Action granularity: Assignments and returns generally perform one action per line; the fluent chain separates each setter clearly. Reading flow: Consistent formatting and straightforward delegation support natural reading, but inconsistent naming and the deadline helper appearing before fields interrupt the flow slightly.
Run 3
Code Structure: Fields, constructors, and accessors are logically grouped, although the static helper preceding the fields slightly interrupts organization. Nesting: Very shallow, with no complex branching or loops. Clarity of intent: Descriptive field names help, but vague method names such as request, request2, pri, and apply, plus numbered constructor parameters, obscure purpose. The quota method's documentation references requestedPartitionCount rather than its actual parameter, requested. Code length: Concise overall; constructor delegation avoids duplicated initialization, and the overloads serve distinct use cases. Action granularity: Most lines perform one action; the fluent header construction is clearly separated into individual setter calls. Reading flow: Consistent indentation and straightforward delegation make execution easy to follow, but inconsistent naming and sparse documentation require readers to infer semantics.