[ 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)