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 that's what we report) 
and we gradually try to delete it (and gradually decrement the total lag with 
what we have deleted). 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