[
https://issues.apache.org/jira/browse/FLINK-13478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896123#comment-16896123
]
Piotr Nowojski commented on FLINK-13478:
----------------------------------------
It sounds fine for me (modulo my lack of expertise for the batch), however is
this fixing some behaviour or just a pure refactoring? If the second one maybe
it would be better to leave it as it is if the current implementation/code is
just simpler?
> 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)
