dajac commented on code in PR #14629:
URL: https://github.com/apache/kafka/pull/14629#discussion_r1379784888
##########
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:
Sorry, I am late here. I actually faced a similar issue while implementing
this API in the new group coordinator. The scenario is more or less the same.
We need to guarantee that the update to the state machine and to the log are
done together to guarantee the ordering of the changes.
Given this, I wonder if we should just change how we do it. I was about to
re-implement this part to work as follow:
1) Verify the transaction and possibly go the transaction coordinator;
2) Execute the actual transactional offset commit logic (update state +
write).
I think that this is easier than introducing extra bookkeeping to track
dependencies. What do you think? Note that I need to change it anyway for the
new coordinator.
One way would be to bring this logic to the KafkaApis layer or we could
rework the write logic within the group coordinator. Would it make sense?
--
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]
