[
https://issues.apache.org/jira/browse/FLINK-13478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896163#comment-16896163
]
zhijiang commented on FLINK-13478:
----------------------------------
I think it might belong to a pure refactoring.
>From behavior aspect, this fix would only speed the release of partition
>resource if the release call from JM is already reaching on TM side, no need
>to wait for consumers' network confirmation. But it seems no matter to release
>partitions a bit delay based on the assumption that the partition
>canceled/consumed would be finally confirmed via network once establishment.
It mainly brings a bit confusing to understand the partition release strategy.
If the strategy of partition release is based on JM's decision which is always
reliable, then it should not be blocked/delayed by network notification.
We could focus on it if necessary in 1.10 release.
> Decouple two different release strategies in BoundedBlockingSubpartition
> ------------------------------------------------------------------------
>
> Key: FLINK-13478
> URL: https://issues.apache.org/jira/browse/FLINK-13478
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Coordination, Runtime / Network
> Reporter: zhijiang
> Assignee: zhijiang
> Priority: Minor
>
> We have two basic release strategies atm. One is based on consumption via
> network notification from consumer. The other is based on notification via
> RPC from JM/scheduler.
> But in current implementation of {{BoundedBlockingSubpartition}}, these two
> ways are coupled with each other. In detail, the network consumption
> notification could only close data file after the release RPC was triggered
> from JM/scheduler. Also for the release RPC it has to wait all the reader
> views really released before closing the data file. So the release RPC still
> relies on network notification to some extent.
> In order to make these two release strategies independent, if the release
> call is from JM/scheduler RPC, we could immediately release all the view
> readers and then close the data file as well. If the release is based on
> consumption notification, after all the view readers for one subpartition are
> released, the subpartition could further notify the parent
> {{ResultPartition}} which decides whether to release the whole partition or
> not.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
