adixitconfluent commented on code in PR #18959:
URL: https://github.com/apache/kafka/pull/18959#discussion_r1965707920
##########
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:
so basically the global variable would be the addition of time spent to make
a call to `acquirablePartitions` from tryComplete when we are unable to acquire
any partitions and then using it once we are finally able to acquire any
partitions. That should give us the total time spent in contention for topic
partitions. Having said that, these times would be minimal (since they are just
function calls) and won't give a high enough time for us to judge contention.
So, I think your current approach should work correctly in giving the time
for contention for topic partitions. However, if tryComplete is not called too
often (due to a bigger problem in the system), then we won't have contention
time. We would be getting the wait time of requests in that scenario. But, I
agree that scenario is extremely rare. Maybe, we can change the doc in the KIP
for this metric to better reflect the meaning in exceptional scenarios.
--
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
