jolshan commented on code in PR #14629:
URL: https://github.com/apache/kafka/pull/14629#discussion_r1376662251
##########
core/src/main/scala/kafka/server/ReplicaManager.scala:
##########
@@ -864,6 +778,111 @@ class ReplicaManager(val config: KafkaConfig,
}
}
+ /*
+ * Note: This method can be used as a callback in a different request
thread. Ensure that correct RequestLocal
+ * is passed when executing this method. Accessing non-thread-safe data
structures should be avoided if possible.
+ */
+ private def appendEntries(allEntries: Map[TopicPartition, MemoryRecords],
+ internalTopicsAllowed: Boolean,
+ origin: AppendOrigin,
+ requiredAcks: Short,
+ verificationGuards: Map[TopicPartition,
VerificationGuard],
Review Comment:
> I am wondering about the locking model. We have the following path that's
called under the GroupMetadata lock. GroupCoordinator.doSyncGroup (hold
GroupMetadata lock) => groupManager.storeGroup => appendForGroup =>
replicaManager.appendRecords => replicaManager.appendEntries. However, if we
register the callback, replicaManager.appendEntries will be called without
holding the GroupMetadata lock. Is that safe?
Hmm. Do we need the lock to write to log or just to updaet the in-memory
state. I can take another look at this path.
--
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
