junrao commented on a change in pull request #8657:
URL: https://github.com/apache/kafka/pull/8657#discussion_r465179335
##########
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:
Hmm, it seems that we are now introducing a new potential deadlock. The
conflicting paths are the following.
path 1
hold group lock -> joinPurgatory.tryCompleteElseWatch(delayedJoin) ->
watchForOperation (now delayedJoin visible through other threads) ->
operation.maybeTryComplete() -> hold delayedJoin.lock
path 2
delayedJoin.maybeTryComplete -> hold hold delayedJoin.lock -> tryComplete()
-> hold group lock
----------------------------------------------------------------
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
