Source code
package org.apache.kafka.coordinator.share;
import org.apache.kafka.server.share.SharePartitionKey; import org.apache.kafka.timeline.SnapshotRegistry;
import org.apache.kafka.timeline.TimelineHashMap;
import org.apache.kafka.timeline.TimelineLong;
import java.util.Objects;
import java.util.Optional; /**
* Util class to track the offsets written into the internal topic
* per share partition key.
* It calculates the minimum offset globally up to which the records
* in the internal partition are redundant i.e. they have been overridden
* by newer records.
*/
public class ShareCoordinatorOffsetsManager {
// Map to store share partition key => current partition offset
// being written.
private final TimelineHashMap<SharePartitionKey, Long> offsets; // Minimum offset representing the smallest necessary offset
// across the internal partition (offsets below this are redundant).
// We are using timeline object here because the offsets which are passed into
// updateState might not be committed yet. In case of retry, these offsets would
// be invalidated via the snapshot registry. Hence, using timeline object
// the values would automatically revert in accordance with the last committed offset.
private final TimelineLong lastRedundantOffset;
public ShareCoordinatorOffsetsManager(SnapshotRegistry snapshotRegistry) { Objects.requireNonNull(snapshotRegistry); offsets = new TimelineHashMap<>(snapshotRegistry, 0);
lastRedundantOffset = new TimelineLong(snapshotRegistry);
lastRedundantOffset.set(Long.MAX_VALUE); // For easy application of Math.min.
}
/**
* Method updates internal state with the supplied offset for the provided
* share partition key. It then calculates the minimum offset, if possible,
* below which all offsets are redundant.
*
* @param key - represents {@link SharePartitionKey} whose offset needs updating
* @param offset - represents the latest partition offset for provided key
* @param isDelete - true if the offset is for a tombstone record
*/ public void updateState(SharePartitionKey key, long offset, boolean isDelete) { lastRedundantOffset.set(Math.min(lastRedundantOffset.get(), offset));
offsets.put(key, offset);
Optional<Long> redundantOffset = findRedundantOffset();
redundantOffset.ifPresent(lastRedundantOffset::set); // If the share partition is deleted, we should not hold onto its offset in our calculations
// as there is nothing beyond deletion which is going to update its state.
if (isDelete) { offsets.remove(key); } }
private Optional<Long> findRedundantOffset() {
if (offsets.isEmpty()) {
return Optional.empty();
}
long soFar = Long.MAX_VALUE;
for (long offset : offsets.values()) {
// Get min offset among latest offsets
// for all share keys in the internal partition.
soFar = Math.min(soFar, offset);
// lastRedundantOffset represents the smallest necessary offset
// and if soFar equals it, we cannot proceed. This can happen
// if a share partition key hasn't had records written for a while.
// For example,
// <p>
// key1:1
// key2:2 4 6
// key3:3 5 7
// <p>
// We can see in above that offsets 2, 4, 3, 5 are redundant,
// but we do not have a contiguous prefix starting at lastRedundantOffset
// and we cannot proceed.
if (soFar == lastRedundantOffset.get()) {
return Optional.of(soFar); }
} return Optional.of(soFar);
}
/**
* Most recent last redundant offset. This method is to be used
* when the caller wants to query the value of such offset.
* @return Optional of type Long representing the offset or empty for invalid offset values
*/
public Optional<Long> lastRedundantOffset() { long value = lastRedundantOffset.get(); if (value <= 0 || value == Long.MAX_VALUE) { return Optional.empty(); } return Optional.of(value);
} // visible for testing
TimelineHashMap<SharePartitionKey, Long> curState() {
return offsets; }
}
Run 1
The code is generally understandable, but its readability is compromised by inconsistent formatting and documentation style. Comments are often misplaced (e.g., trailing after code, or obscure functional intent). The class's purpose is documented, but method-level explanations are verbose or insufficient in places. Nesting is acceptable, though there is some logical duplication in 'updateState' and 'findRedundantOffset' around maintaining min offsets. 'updateState' performs several operations (setting min, putting data, optionally removing) in one method, reducing action granularity. The one-liner constructor and other compressed code hinder scanning. Javadoc and inline comments are inconsistently placed and sometimes poorly describe the logic. Overall, the code could be much clearer with better formatting, clearer comments, and more granular method extraction.
Run 2
The code has logical structure and reasonable method separation, but readability is significantly hampered by formatting issues. Multiple statements are compressed onto single lines, particularly in the constructor, updateState method, and closing braces, violating 'one action per line.' Javadoc comments are inconsistently placed and sometimes misaligned with their corresponding code. Import statements are run together without spacing. While nesting is minimal and action granularity is mostly acceptable, the poor formatting disrupts reading flow and forces readers to parse densely packed lines. The class purpose is clear, and the algorithm logic is understandable, but the presentation undermines clarity. With proper line breaks and formatting, this code would be significantly more readable.
Run 3
The code is poorly structured and difficult to read. Several methods are compressed into single lines with multiple statements (e.g., updateState and lastRedundantOffset), violating action granularity and reading flow. Imports are collapsed onto one line, and some comments are inline or misplaced, disrupting logical organization. Nesting is shallow, which is good, but clarity of intent suffers due to dense formatting, minimal whitespace, and unclear separation of concerns. The findRedundantOffset method contains a long explanation inside a loop that breaks flow. While the class-level comments are helpful, the inconsistent formatting and lack of structure make the code significantly harder to scan and maintain. Overall, the code is functional but visually cluttered and unnecessarily dense, reducing readability.
Run 1
Code Structure: Responsibilities are sensibly separated into initialization, state updates, minimum-offset calculation, and accessors, but inconsistent formatting obscures those boundaries. Nesting: Shallow loops and conditionals with early returns keep complexity low. Clarity of intent: Descriptive class and method names plus explanatory comments establish the purpose, although 'soFar' is vague and redundant-versus-necessary offset terminology requires careful interpretation. Code length: The implementation is compact, but lengthy comments and compressed methods make its presentation uneven. Action granularity: Several imports, assignments, conditionals, and returns share lines, reducing scanability. Reading flow: Logical method order helps, but comments attached to unrelated declarations, inline braces, and collapsed methods interrupt natural reading. Overall, the logic is approachable, while formatting substantially weakens readability.
Run 2
Code Structure: Fields and focused methods provide logical organization, but inconsistent formatting obscures boundaries. Nesting: Mostly shallow, with straightforward conditionals and one loop. Clarity of intent: Descriptive names and explanatory comments communicate offset tracking, although redundant-offset terminology and deletion ordering require careful reading. Code length: The implementation is reasonably concise, but lengthy comments and repetitive documentation add reading overhead. Action granularity: Several imports, assignments, conditionals, and returns share lines, making individual operations harder to distinguish. Reading flow: The overall progression from initialization to updates, calculation, and accessors is natural, but cramped method declarations, misplaced inline comments, and same-line closing braces repeatedly interrupt scanning.
Run 3
Code Structure: Fields and focused methods provide logical organization, but inconsistent formatting blurs boundaries. Nesting: Mostly shallow, with a straightforward loop and simple conditionals. Clarity of intent: Descriptive names and documentation explain offset tracking and snapshot behavior, although redundant versus necessary offset terminology requires careful reading. Code length: The implementation is reasonably concise, but lengthy comments and repetitive documentation interrupt it. Action granularity: Multiple imports, constructor operations, conditionals, and returns share lines, making individual actions harder to scan. Reading flow: The overall sequence is sensible, but inline comments, compressed method declarations, and misplaced closing braces disrupt natural reading. Consistent formatting and more focused comments would substantially improve readability.