[
https://issues.apache.org/jira/browse/FLINK-13478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhijiang closed FLINK-13478.
----------------------------
Resolution: Won't Fix
This issue is out of date since partition release logics have changed a lot
before.
Close it for cleanup and we can review it again if really necessary future.
> 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 a bit coupled with each other. If the JM decides to release
> partition and send the release RPC call, it has to wait all the reader views
> really released before finally closing the data file. So the JM-RPC-based
> release strategy still relies on the consumption confirmation via network 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 confirmation, 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
(v8.3.4#803005)
