kamalcph commented on code in PR #15005:
URL: https://github.com/apache/kafka/pull/15005#discussion_r1428638499
##########
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:
Why are we changing the deletion behaviour? When this replica is not the
leader, then we want to skip the segment deletion.
Should we have to record the `remoteDeleteLagBytes` and
`remoteDeleteLagSegments` for `deletion-due-to-leader-epoch-cache-truncation`
case? The deletion is happening in-sync and those metrics may not be relevant.
For the below cases, recording of the deletion-lag-metrics seem valid since
there can be some delay b/w marking the eligible segments and actually deleting
them:
1. breachByLogStartOffset
2. breachByRetentionTime and
3. breachByRetentionSize
##########
core/src/main/scala/kafka/server/KafkaRequestHandler.scala:
##########
@@ -524,7 +567,7 @@ class BrokerTopicStats(configOpt:
java.util.Optional[KafkaConfig] = java.util.Op
topicMetrics.closeMetric(RemoteStorageMetrics.REMOTE_COPY_REQUESTS_PER_SEC_METRIC.getName)
topicMetrics.closeMetric(RemoteStorageMetrics.FAILED_REMOTE_FETCH_PER_SEC_METRIC.getName)
topicMetrics.closeMetric(RemoteStorageMetrics.FAILED_REMOTE_COPY_PER_SEC_METRIC.getName)
-
topicMetrics.closeMetric(RemoteStorageMetrics.REMOTE_COPY_LOG_BYTES_METRIC.getName)
+
topicMetrics.closeMetric(RemoteStorageMetrics.REMOTE_COPY_LAG_BYTES_METRIC.getName)
Review Comment:
Shall we close the `RemoteCopyLagSegments`, `RemoteDeleteLagBytes`, and
`RemoteDeleteLagSegments` metrics here?
##########
core/src/main/scala/kafka/server/KafkaRequestHandler.scala:
##########
@@ -397,16 +400,56 @@ class BrokerTopicMetrics(name: Option[String], configOpt:
java.util.Optional[Kaf
def invalidOffsetOrSequenceRecordsPerSec: Meter =
metricTypeMap.get(BrokerTopicStats.InvalidOffsetOrSequenceRecordsPerSec).meter()
def recordRemoteCopyBytesLag(partition: Int, bytesLag: Long): Unit = {
Review Comment:
Subjective: Please consider renaming all the method/metric names to be
consistent:
```
MetricName -> MethodName
RemoteCopyLagBytes -> recordRemoteCopyLagBytes()
```
(or)
```
MethodName -> MetricName
recordRemoteCopyBytesLag() -> RemoteCopyBytesLag
```
It brings clarity to the code.
--
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]
