[
https://issues.apache.org/jira/browse/FLINK-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15871538#comment-15871538
]
Stefan Richter commented on FLINK-2491:
---------------------------------------
This seems still valid, but I assume it is not in progress anymore. I think the
reason for the problem is that some operator instances might shutdown at some
point, but the checkpoint coordinator is still expecting all instances that
were initially started to confirm in a checkpoint. What we would need is some
way to unregister operator instances from checkpointing after their shutdown.
Also this should be reestablished in case of restarts. Is this summary correct
[~aljoscha] [~StephanEwen]?
> Operators are not participating in state checkpointing in some cases
> --------------------------------------------------------------------
>
> Key: FLINK-2491
> URL: https://issues.apache.org/jira/browse/FLINK-2491
> Project: Flink
> Issue Type: Bug
> Components: Streaming
> Affects Versions: 0.10.0
> Reporter: Robert Metzger
> Assignee: Márton Balassi
> Priority: Critical
> Fix For: 1.0.0
>
>
> While implementing a test case for the Kafka Consumer, I came across the
> following bug:
> Consider the following topology, with the operator parallelism in parentheses:
> Source (2) --> Sink (1).
> In this setup, the {{snapshotState()}} method is called on the source, but
> not on the Sink.
> The sink receives the generated data.
> only one of the two sources is generating data.
> I've implemented a test case for this, you can find it here:
> https://github.com/rmetzger/flink/blob/para_checkpoint_bug/flink-tests/src/test/java/org/apache/flink/test/checkpointing/ParallelismChangeCheckpoinedITCase.java
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
