[
https://issues.apache.org/jira/browse/FLINK-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899212#comment-15899212
]
ASF GitHub Bot commented on FLINK-4714:
---------------------------------------
Github user StephanEwen commented on the issue:
https://github.com/apache/flink/pull/3474
@tony810430 That's a good idea, let's have a two argument constructor with
`Environment` and `TaskStateHandles `.
The `AbstractInvokable` and its subclasses are a very low level internal
API. It is okay if we make this a "contract" that they need this constructor -
runtime will fail the task otherwise.
In fact, there are only two main implementations of the
`AbstractInvokable`: ``StreamTask` and `BatchTask`, with some subclasses. That
is okay to manage.
The benefit of having eager initialization of fields and state is much
higher than the burden to add the constructor.
> Set task state to RUNNING after state has been restored
> -------------------------------------------------------
>
> Key: FLINK-4714
> URL: https://issues.apache.org/jira/browse/FLINK-4714
> Project: Flink
> Issue Type: Improvement
> Components: Distributed Coordination, State Backends, Checkpointing
> Affects Versions: 1.2.0
> Reporter: Till Rohrmann
> Assignee: Wei-Che Wei
>
> The task state is set to {{RUNNING}} as soon as the {{Task}} is executed.
> That, however, happens before the state of the {{StreamTask}} invokable has
> been restored. As a result, the {{CheckpointCoordinator}} starts to trigger
> checkpoints even though the {{StreamTask}} is not ready.
> In order to avoid aborting checkpoints and properly start it, we should
> switch the task state to {{RUNNING}} after the state has been restored.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
