[
https://issues.apache.org/jira/browse/FLINK-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16106669#comment-16106669
]
ASF GitHub Bot commented on FLINK-7213:
---------------------------------------
Github user StefanRRichter commented on the issue:
https://github.com/apache/flink/pull/4353
I think that idea is problematic because in the rescaling case, all the
collections can have different sizes. For example there can be 5 managed keyed
state handles and 7 managed operator state handles and zero state handles for
the raw state. Then how would you split that up between the
`OperatorSubtaskStates` in your set? Like this, `OperatorSubtaskState` contains
the complete state for an operator subtask which I think is a good thing. Also
maybe at some point there *might* be a reason to report more than one handle
already on snapshotting.
> Introduce state management by OperatorID in TaskManager
> -------------------------------------------------------
>
> Key: FLINK-7213
> URL: https://issues.apache.org/jira/browse/FLINK-7213
> Project: Flink
> Issue Type: Improvement
> Components: State Backends, Checkpointing
> Affects Versions: 1.4.0
> Reporter: Stefan Richter
> Assignee: Stefan Richter
>
> Flink-5892 introduced the job manager / checkpoint coordinator part of
> managing state on the operator level instead of the task level by introducing
> explicit operator_id -> state mappings. However, this explicit mapping was
> not introduced in the task manager side, so the explicit mapping is still
> converted into a mapping that suits the implicit operator chain order.
> We should also introduce explicit operator ids to state management on the
> task manager.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
