zhijiangW commented on a change in pull request #7186: [FLINK-10941] Keep slots
which contain unconsumed result partitions
URL: https://github.com/apache/flink/pull/7186#discussion_r238983295
##########
File path:
flink-runtime/src/main/java/org/apache/flink/runtime/io/network/netty/PartitionRequestQueue.java
##########
@@ -134,10 +138,17 @@ public void cancel(InputChannelID receiverId) {
ctx.pipeline().fireUserEventTriggered(receiverId);
}
- public void close() {
+ public void close() throws IOException {
if (ctx != null) {
ctx.channel().close();
}
+
+ LOG.info("Close all {} readers pending for close.",
readersToClose.size());
Review comment:
Sorry for late response because of a little busy these days.
I agree with your above comments. So whether the task executor can be
released is based on whether there are active channels in this executor. The
task executor can only exit after all the tcp connections are closed gracefully.
In theory as long as the downstream received all the data from the network,
then the upstream side can be released normally, no need to wait all the
received data are processed completely by downstream side. But we have on
existing ack mechanism to notify upstream side of this, so it is easy to rely
on close request currently. Based on downstream's consumption to release
upstream's resource, it may get extra benefits in failover scenarios in future
for persistent output files in upstream side, because the upstream do not need
to restart during consumption exception in downstream side.
But I just a little wonder it might bring potential effects in future via
close request. For example, if there are 10 downstream tasks reuse the same tcp
connection, and 9 tasks are finished earlier and only one tail task delay long
to finish, then all the 10 partition views must be released together until the
last downstream task finished. Although it might be no bad effects for delay
releasing partition views currently.
I would continue reviewing other parts of this PR and it may take some days
on my side. :)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
