kamalcph commented on code in PR #17659:
URL: https://github.com/apache/kafka/pull/17659#discussion_r1830355048
##########
core/src/main/java/kafka/log/remote/RemoteLogManager.java:
##########
@@ -1803,6 +1842,37 @@ Optional<RemoteLogSegmentMetadata>
findNextSegmentMetadata(RemoteLogSegmentMetad
: Optional.empty();
}
+ /**
+ * Returns the next segment that contains the aborted transaction entries.
The search ensures that the returned
+ * segment offsets are greater than or equal to the given offset.
+ * @param tp The topic partition.
+ * @param offset The offset to start the search.
+ * @param fileCache The leader epoch file cache.
+ * @return The next segment that contains the transaction index.
+ * @throws RemoteStorageException If an error occurs while fetching the
remote log segment metadata.
+ */
+ Optional<RemoteLogSegmentMetadata>
findNextSegmentWithTxnIndex(TopicPartition tp,
+ long offset,
+
LeaderEpochFileCache fileCache) throws RemoteStorageException {
+ Optional<RemoteLogSegmentMetadata> metadataOpt = Optional.empty();
+ if (fileCache != null) {
+ OptionalInt initialEpochOpt = fileCache.epochForOffset(offset);
+ if (initialEpochOpt.isPresent()) {
+ int initialEpoch = initialEpochOpt.getAsInt();
+ for (EpochEntry epochEntry : fileCache.epochEntries()) {
Review Comment:
> Asking because all RLMM implementations may not have a way to figure out
nextSegmentWithTrxIndex directly.
Agree, we provide both the options to the implementors.
* The default implementation is to return the segment metadata that matches
the given offset and epoch (same as
R[LMM#remoteLogSegmentMetadata(topicIdPartition, epoch,
offset)](https://sourcegraph.com/github.com/apache/kafka/-/blob/storage/api/src/main/java/org/apache/kafka/server/log/remote/storage/RemoteLogMetadataManager.java?L123)
method).
* The plugin implementors can optimize their search by returning the next
segment metadata that contains the transaction index in the same epoch (or)
return empty in which case we proceed the search to the (next-epoch,
start-offset).
##########
core/src/main/java/kafka/log/remote/RemoteLogManager.java:
##########
@@ -1803,6 +1842,37 @@ Optional<RemoteLogSegmentMetadata>
findNextSegmentMetadata(RemoteLogSegmentMetad
: Optional.empty();
}
+ /**
+ * Returns the next segment that contains the aborted transaction entries.
The search ensures that the returned
+ * segment offsets are greater than or equal to the given offset.
+ * @param tp The topic partition.
+ * @param offset The offset to start the search.
+ * @param fileCache The leader epoch file cache.
+ * @return The next segment that contains the transaction index.
+ * @throws RemoteStorageException If an error occurs while fetching the
remote log segment metadata.
+ */
+ Optional<RemoteLogSegmentMetadata>
findNextSegmentWithTxnIndex(TopicPartition tp,
+ long offset,
+
LeaderEpochFileCache fileCache) throws RemoteStorageException {
+ Optional<RemoteLogSegmentMetadata> metadataOpt = Optional.empty();
+ if (fileCache != null) {
+ OptionalInt initialEpochOpt = fileCache.epochForOffset(offset);
+ if (initialEpochOpt.isPresent()) {
+ int initialEpoch = initialEpochOpt.getAsInt();
+ for (EpochEntry epochEntry : fileCache.epochEntries()) {
Review Comment:
> Asking because all RLMM implementations may not have a way to figure out
nextSegmentWithTrxIndex directly.
Agree, we provide both the options to the implementors.
* The default implementation is to return the segment metadata that matches
the given offset and epoch (same as
[RLMM#remoteLogSegmentMetadata(topicIdPartition, epoch,
offset)](https://sourcegraph.com/github.com/apache/kafka/-/blob/storage/api/src/main/java/org/apache/kafka/server/log/remote/storage/RemoteLogMetadataManager.java?L123)
method).
* The plugin implementors can optimize their search by returning the next
segment metadata that contains the transaction index in the same epoch (or)
return empty in which case we proceed the search to the (next-epoch,
start-offset).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
