chia7712 commented on a change in pull request #8657:
URL: https://github.com/apache/kafka/pull/8657#discussion_r465206257
##########
File path: core/src/main/scala/kafka/coordinator/group/GroupCoordinator.scala
##########
@@ -369,6 +370,32 @@ class GroupCoordinator(val brokerId: Int,
}
}
+ /**
+ * try to complete produce, fetch and delete requests if the HW of partition
is incremented. Otherwise, we try to complete
+ * only delayed fetch requests.
+ *
+ * Noted that this method may hold multiple group locks so the caller should
NOT hold any group lock
+ * in order to avoid deadlock
+ * @param topicPartitions a map contains the partition and a flag indicting
whether the HWM has been changed
+ */
+ private[group] def completeDelayedRequests(topicPartitions:
Map[TopicPartition, LeaderHwChange]): Unit =
+ topicPartitions.foreach {
+ case (tp, leaderHWIncremented) => leaderHWIncremented match {
+ case LeaderHwIncremented =>
groupManager.replicaManager.completeDelayedRequests(tp)
+ case _ => groupManager.replicaManager.completeDelayedFetchRequests(tp)
+ }
+ }
+
+ /**
+ * complete the delayed join requests associated to input group keys.
+ *
+ * Noted that delayedJoin itself uses a lock other than the group lock for
DelayedOperation.maybeTryComplete() and
Review comment:
another approach is that - we introduce an new method "afterTryComplete"
to ```DelayedOperation```. the new method is invoked by ```maybeTryComplete```
after lock is released. ```DelayedJoin``` still pass group lock to
```DelayedOperation``` and use "afterTryComplete" to complete delayed requests
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
