chickenchickenlove commented on code in PR #23923:
URL: https://github.com/apache/kafka/pull/23923#discussion_r4369998732
##########
coordinator-common/src/main/java/org/apache/kafka/coordinator/common/runtime/CoordinatorExecutorImpl.java:
##########
@@ -232,6 +245,39 @@ public void cancelAll() {
tasks.keySet().forEach(this::cancel);
}
+ /**
+ * Submits the tasks scheduled by the operations in the current batch, now
that the batch
+ * has been written.
+ */
+ public void onBatchWritten() {
Review Comment:
How do we ensure that the tasks in currentBatchTasks belong to the batch
being flushed?
An operation may schedule a task while generating its records, before
`append()` is called. If `append()` then needs to flush the previous batc--for
example, because the new records do not fit--could `onBatchWritten()` submit
that task before its own records have been appended?
If the subsequent append fails, the task may already have been submitted
even though the records it depends on were not written. Is there a guarantee
that prevents this sequence, or do we need to associate the tasks more
explicitly with their batch?
(I'm struggling with this in KAFKA-19023 as well. 😓 )
--
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]
