bowenli86 commented on code in PR #283:
URL:
https://github.com/apache/flink-connector-kafka/pull/283#discussion_r3545748736
##########
flink-connector-kafka/src/main/java/org/apache/flink/connector/kafka/dynamic/source/reader/DynamicKafkaSourceReader.java:
##########
@@ -405,11 +405,18 @@ private void releasePendingSplitOutputs(ReaderOutput<T>
readerOutput) {
}
for (String splitId : pendingSplitOutputReleases) {
- readerOutput.releaseOutputForSplit(splitId);
+ markSplitIdleAndReleaseOutput(readerOutput, splitId);
}
pendingSplitOutputReleases.clear();
}
+ private void markSplitIdleAndReleaseOutput(ReaderOutput<T> readerOutput,
String splitId) {
+ // Unregistering a split output does not recompute Flink's split-local
watermark or
+ // idleness. Mark it idle first so a removed split cannot keep the
source output active.
+ readerOutput.createOutputForSplit(splitId).markIdle();
Review Comment:
Could we add a regression test for the case where the last split is removed
and then a split is re-added before the next `pollNext()`? In that sequence,
this `markIdle()` may already expose the source as idle while
`dynamicOutputIdle` remains `false`, so the active path may not call
`markActive()` again. I wonder if explicitly reactivating on split re-add, or
covering this ordering in a test, would help avoid records flowing while
downstream still sees the source as idle.
--
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]
