chirag-wadhwa5 commented on code in PR #19637:
URL: https://github.com/apache/kafka/pull/19637#discussion_r2078447273
##########
core/src/main/scala/kafka/server/KafkaApis.scala:
##########
@@ -3049,6 +3049,11 @@ class KafkaApis(val requestChannel: RequestChannel,
// Creating the shareFetchContext for Share Session Handling. if context
creation fails, the request is failed directly here.
shareFetchContext = sharePartitionManager.newContext(groupId,
shareFetchData, forgottenTopics, newReqMetadata, isAcknowledgeDataPresent,
request.context.connectionId)
} catch {
+ case e: ShareSessionLimitReachedException =>
+ // Throttle for maxWaitMs when share session limit is reached
+ requestHelper.throttle(quotas.request, request,
shareFetchRequest.maxWait)
Review Comment:
I revisited the code. I was wrong before, even when the SHARE_FETCH request
is throttled, the SHARE_GROUP_HEARTBEAT requests would not be interfered with.
This has been verified with the following manual test as well ->
I set the max wait time to 6 seconds, and share group heartbeat interval to
500 ms. So, when a new share session was being tried to initialize when the
cache was already full, the share fetch requests were throttled, and I could
see a delay of more than 6 seconds between successive share fetch requests. But
I could see heartbeats being sent and received during that the throttling
duration at regular intervals of approx 500ms. So the throttling logic did not
change the heartbeats and the member continued to maintain its existence with a
group, even though fetching was not happening.
--
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
