clolov commented on code in PR #15005:
URL: https://github.com/apache/kafka/pull/15005#discussion_r1430372576


##########
core/src/main/java/kafka/log/remote/RemoteLogManager.java:
##########
@@ -1073,13 +1088,28 @@ void cleanupExpiredRemoteLogSegments() throws 
RemoteStorageException, ExecutionE
                         .iterator();
                 while (epochsToClean.hasNext()) {
                     int epoch = epochsToClean.next();
+                    List<RemoteLogSegmentMetadata> listOfSegmentsToBeCleaned = 
new ArrayList<>();
                     Iterator<RemoteLogSegmentMetadata> segmentsToBeCleaned = 
remoteLogMetadataManager.listRemoteLogSegments(topicIdPartition, epoch);
                     while (segmentsToBeCleaned.hasNext()) {
                         if (isCancelled() || !isLeader()) {
                             return;
+                        } else {
+                            RemoteLogSegmentMetadata nextSegmentMetadata = 
segmentsToBeCleaned.next();
+                            sizeOfDeletableSegmentsBytes += 
nextSegmentMetadata.segmentSizeInBytes();
+                            listOfSegmentsToBeCleaned.add(nextSegmentMetadata);
                         }
+                    }
+                    segmentsLeftToDelete += listOfSegmentsToBeCleaned.size();
+                    brokerTopicMetrics.recordRemoteDeleteBytesLag(partition, 
sizeOfDeletableSegmentsBytes);
+                    
brokerTopicMetrics.recordRemoteDeleteSegmentsLag(partition, 
segmentsLeftToDelete);
+                    for (RemoteLogSegmentMetadata segmentMetadata : 
listOfSegmentsToBeCleaned) {
                         // No need to update the log-start-offset even though 
the segment is deleted as these epochs/offsets are earlier to that value.
-                        
remoteLogRetentionHandler.deleteLogSegmentsDueToLeaderEpochCacheTruncation(earliestEpochEntry,
 segmentsToBeCleaned.next());
+                        if 
(remoteLogRetentionHandler.deleteLogSegmentsDueToLeaderEpochCacheTruncation(earliestEpochEntry,
 segmentMetadata)) {

Review Comment:
   Sorry, I am afraid I do not understand why would the lag become invalid. In 
my head, we start from everything we need to delete and we gradually try to 
delete it. If at any point in time secondary storage throws a tantrum then the 
lag is the difference between what we were last successfully able to delete and 
what we should have deleted up to. On the next deletion iteration we should 
pick up the segments we were unable to delete and they would be included in the 
calculation again. Am I missing something obvious here?



-- 
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]

Reply via email to