[jira] [Updated] (FLINK-13754) Decouple OperatorChain with StreamStatusMaintainer
[ https://issues.apache.org/jira/browse/FLINK-13754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhijiang updated FLINK-13754: - Description: The current OperatorChain is heavy-weight to take some unrelated roles like _StreamStatusMaintainer_. If other components rely on the _StreamStatusMaintainer_, we have to pass the whole OperatorChain. From the design aspect of single function, we need to decouple _StreamStatusMaintainer_ from _OperatorChain_. Based on FLINK-13798 to break the cycle dependency between _RecordWriterOutput_ and _StreamStatusMaintainer,_ it is reasonable to create/maintain a separate instance of _StreamStatusMaintainer_ on StreamTask side. One reason is that it gets benefits of removing some duplicate logics while creating _RecordWriter_ and _RecordWriterOutput_ together. Another reason is that it is easy to reference the _StreamStatusMaintainer_ via _StreamTask_ in the following refactoring work. was: The current OperatorChain is heavy-weight to take some unrelated roles like StreamStatusMaintainer. If other components only rely on the StreamStatusMaintainer, we have to pass the whole OperatorChain. From the design aspect of single function, we need to decouple StreamStatusMaintainer from OperatorChain. The solution is to refactor the creation of StreamStatusMaintainer and RecordWriterOutput in StreamTask level, and then break the implementation cycle dependency between them. The array of RecordWriters which has close relationship with RecordWriterOutput is created in StreamTask, so it is reasonable to create them together. The created StreamStatusMaintainer in StreamTask can be directly referenced by subclasses like OneInputStreamTask/TwoInputStreamTask. > Decouple OperatorChain with StreamStatusMaintainer > -- > > Key: FLINK-13754 > URL: https://issues.apache.org/jira/browse/FLINK-13754 > Project: Flink > Issue Type: Sub-task > Components: Runtime / Task >Reporter: zhijiang >Assignee: zhijiang >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The current OperatorChain is heavy-weight to take some unrelated roles like > _StreamStatusMaintainer_. If other components rely on the > _StreamStatusMaintainer_, we have to pass the whole OperatorChain. From the > design aspect of single function, we need to decouple > _StreamStatusMaintainer_ from _OperatorChain_. > Based on FLINK-13798 to break the cycle dependency between > _RecordWriterOutput_ and _StreamStatusMaintainer,_ it is reasonable to > create/maintain a separate instance of _StreamStatusMaintainer_ on StreamTask > side. > One reason is that it gets benefits of removing some duplicate logics while > creating _RecordWriter_ and _RecordWriterOutput_ together. > Another reason is that it is easy to reference the _StreamStatusMaintainer_ > via _StreamTask_ in the following refactoring work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (FLINK-13754) Decouple OperatorChain with StreamStatusMaintainer
[ https://issues.apache.org/jira/browse/FLINK-13754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhijiang updated FLINK-13754: - Description: The current OperatorChain is heavy-weight to take some unrelated roles like StreamStatusMaintainer. If other components only rely on the StreamStatusMaintainer, we have to pass the whole OperatorChain. From the design aspect of single function, we need to decouple StreamStatusMaintainer from OperatorChain. The solution is to refactor the creation of StreamStatusMaintainer and RecordWriterOutput in StreamTask level, and then break the implementation cycle dependency between them. The array of RecordWriters which has close relationship with RecordWriterOutput is created in StreamTask, so it is reasonable to create them together. The created StreamStatusMaintainer in StreamTask can be directly referenced by subclasses like OneInputStreamTask/TwoInputStreamTask. was: The current OperatorChain is heavy-weight to take some unrelated roles like StreamStatusMaintainer. If other components only rely on the StreamStatusMaintainer, we have to pass the whole OperatorChain. From the design aspect of single function, we need to decouple The solution is to refactor the creation of StreamStatusMaintainer and RecordWriterOutput in StreamTask level, and then break the implementation cycle dependency between them. The array of RecordWriters which has close relationship with RecordWriterOutput is created in StreamTask, so it is reasonable to create them together. The created StreamStatusMaintainer in StreamTask can be directly referenced by subclasses like OneInputStreamTask/TwoInputStreamTask. > Decouple OperatorChain with StreamStatusMaintainer > -- > > Key: FLINK-13754 > URL: https://issues.apache.org/jira/browse/FLINK-13754 > Project: Flink > Issue Type: Sub-task > Components: Runtime / Task >Reporter: zhijiang >Assignee: zhijiang >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The current OperatorChain is heavy-weight to take some unrelated roles like > StreamStatusMaintainer. If other components only rely on the > StreamStatusMaintainer, we have to pass the whole OperatorChain. From the > design aspect of single function, we need to decouple StreamStatusMaintainer > from OperatorChain. > The solution is to refactor the creation of StreamStatusMaintainer and > RecordWriterOutput in StreamTask level, and then break the implementation > cycle dependency between them. The array of RecordWriters which has close > relationship with RecordWriterOutput is created in StreamTask, so it is > reasonable to create them together. The created StreamStatusMaintainer in > StreamTask can be directly referenced by subclasses like > OneInputStreamTask/TwoInputStreamTask. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (FLINK-13754) Decouple OperatorChain with StreamStatusMaintainer
[ https://issues.apache.org/jira/browse/FLINK-13754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhijiang updated FLINK-13754: - Summary: Decouple OperatorChain with StreamStatusMaintainer (was: Decouple OperatorChain from StreamStatusMaintainer) > Decouple OperatorChain with StreamStatusMaintainer > -- > > Key: FLINK-13754 > URL: https://issues.apache.org/jira/browse/FLINK-13754 > Project: Flink > Issue Type: Sub-task > Components: Runtime / Task >Reporter: zhijiang >Assignee: zhijiang >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The current OperatorChain is heavy-weight to take some unrelated roles like > StreamStatusMaintainer. If other components only rely on the > StreamStatusMaintainer, we have to pass the whole OperatorChain. From the > design aspect of single function, we need to decouple > The solution is to refactor the creation of StreamStatusMaintainer and > RecordWriterOutput in StreamTask level, and then break the implementation > cycle dependency between them. The array of RecordWriters which has close > relationship with RecordWriterOutput is created in StreamTask, so it is > reasonable to create them together. The created StreamStatusMaintainer in > StreamTask can be directly referenced by subclasses like > OneInputStreamTask/TwoInputStreamTask. -- This message was sent by Atlassian Jira (v8.3.2#803003)
