Zakelly commented on code in PR #25968:
URL: https://github.com/apache/flink/pull/25968#discussion_r1914214191
##########
flink-runtime/src/main/java/org/apache/flink/runtime/asyncprocessing/AsyncExecutionController.java:
##########
@@ -388,14 +403,13 @@ private void seizeCapacity() {
// 2. If the state request is for a newly entered record, the
in-flight record number should
// be less than the max in-flight record number.
// Note: the currentContext may be updated by {@code
StateFutureFactory#build}.
- if (currentContext.getRecord() != RecordContext.EMPTY_RECORD) {
- // We only drain the records when there is a real record or timer
assigned.
- // Typically, if it is an empty record, this is a derived request
by another request (by
- // initializing a process directly via #asyncProcessWithKey),
meaning that we are in
- // middle of another processing and creating a new one here. If we
block here, there
- // might be a deadlock (current processing waiting here to drain
while draining the
- // current processing).
- // There probably cause the number of records actually run to be
greater than the limit.
+ if (!allowOverdraft) {
+ // We allow a derived request by another request (by initializing
a process directly via
+ // #asyncProcessWithKey, or timer triggering right after a record
processing), meaning
+ // that we are in middle of another processing and creating a new
one here. If we block
+ // here, there might be a deadlock (current processing waiting
here to drain the current
+ // processing, this is a rare case when all the records share the
same key).
+ // This probably cause the number of records actually run to be
greater than the limit.
// But overall it is under-control since there should not be many
derived requests
Review Comment:
There should not be many derived requests. The derived requests are created
when the parent request is under context of one key and it wants to trigger a
request for another key. This is rare and only used by some SQL implement.
The maximum number of requests beyond the limit would be the number of
derived requests from a single request. Typically there should not be many
derived requests, that's what the sentence mean.
Even when there are thousands of requests piled up, it's not a big deal.
Those requests will be drained when next incoming record start progress.
--
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: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
