adixitconfluent commented on code in PR #17739:
URL: https://github.com/apache/kafka/pull/17739#discussion_r1841165543
##########
core/src/main/java/kafka/server/share/DelayedShareFetch.java:
##########
@@ -90,39 +90,50 @@ public void onExpiration() {
*/
@Override
public void onComplete() {
+ // We are utilizing lock so that onComplete doesn't do a dirty read
for global variables -
+ // partitionsAcquired and partitionsAlreadyFetched, since these
variables can get updated in a different tryComplete thread.
+ lock.lock();
log.trace("Completing the delayed share fetch request for group {},
member {}, "
+ "topic partitions {}", shareFetchData.groupId(),
shareFetchData.memberId(),
partitionsAcquired.keySet());
- if (shareFetchData.future().isDone())
- return;
+ try {
+ if (shareFetchData.future().isDone())
+ return;
Review Comment:
So, if we have 2 different keys corresponding to a ShareFetch request, it
could be a case that for one of those keys, we get a `checkAndComplete` call
which could result in completing the share fetch request. Now when the
purgatory entry corresponding to the other key could timeout/have
`checkAndComplete` triggered, when the code reaches onComplete, the share fetch
request's future was already complete, so it would hit
`shareFetchData.future().isDone()` and return true.
--
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
