adixitconfluent commented on code in PR #17177:
URL: https://github.com/apache/kafka/pull/17177#discussion_r1758382532
##########
core/src/main/java/kafka/server/share/DelayedShareFetch.java:
##########
@@ -126,6 +139,16 @@ public void onComplete() {
}
// Releasing the lock to move ahead with the next request
in queue.
releasePartitionLocks(shareFetchPartitionData.groupId(),
topicPartitionData.keySet());
+ // If we have a fetch request completed for a
topic-partition, we release the locks for that partition,
+ // then we should check if there is a pending share fetch
request for the topic-partition and complete it.
+ // We add the action to delayed actions queue to avoid an
infinite call stack, which could happen if
+ // we directly call
delayedShareFetchPurgatory.checkAndComplete
+ delayedActionQueue.add(() -> {
Review Comment:
@mumrah , we created a JIRA
https://issues.apache.org/jira/browse/KAFKA-17522 for tracking this issue
earlier. Yes, it makes sense that share partition `acquire` functionality need
not return a future. I am not sure whether I should cover it in this PR itself.
@apoorvmittal10 any thoughts whether we should cover it in this PR or since
the JIRA is assigned to you, if you're working on it already, we can have
another PR for the resolution?
--
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]
