apoorvmittal10 commented on code in PR #18959:
URL: https://github.com/apache/kafka/pull/18959#discussion_r1965556248
##########
core/src/main/java/kafka/server/share/DelayedShareFetch.java:
##########
@@ -62,9 +63,13 @@ public class DelayedShareFetch extends DelayedOperation {
private final ReplicaManager replicaManager;
private final BiConsumer<SharePartitionKey, Throwable> exceptionHandler;
private final PartitionMaxBytesStrategy partitionMaxBytesStrategy;
+ private final ShareGroupMetrics shareGroupMetrics;
+ private final Time time;
// The topic partitions that need to be completed for the share fetch
request are given by sharePartitions.
// sharePartitions is a subset of shareFetchData. The order of
insertion/deletion of entries in sharePartitions is important.
private final LinkedHashMap<TopicIdPartition, SharePartition>
sharePartitions;
+ // Tracks the start time to acquire any share partition for a fetch
request.
+ private long acquireStartTimeMs;
Review Comment:
Certainly you are not wrong. But I think metrics need that wait time: here
is the comment by Jun from discussion thread and my response:
> 11. I was thinking that it would be useful to know if there is any tension
when acquiring the share partition lock. This is not quite captured by
FetchLockTimeMs. Perhaps we could add another metric that measures the
amount of time that a request needs to wait before acquiring a lock.
> AM Response: I have added TopicPartitionsAcquireTimeMs which can track the
time spent by any share fetch request to acquire any share partition. It's hard
to track the amount of time spent on waiting for a single share partition but
we can track the time spent to acquire any.
My impression is that we should be considering the wait time and any share
partition acquire time itself to see how much time request is spending before
successfully acquiring any lock and proceeding. If the metric purpose is not
reflected in docs then let me know, I ll update them
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
