[
https://issues.apache.org/jira/browse/FLINK-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16219878#comment-16219878
]
ASF GitHub Bot commented on FLINK-7666:
---------------------------------------
Github user StefanRRichter commented on the issue:
https://github.com/apache/flink/pull/4900
I have one quick question, but maybe I miss something big here: wouldn't it
be possible to simply run `quiesceAndAwaitPending()` before `Operator::close()`
and avoid the locking/flag checking and not run into exceptions? If we ensure
that the task is no longer in running state, the "forgotten" timers can no
longer reflect in any checkpoint/savepoint and I think there is no guarantee of
a consistent output after canceling a job anyways?
> ContinuousFileReaderOperator swallows chained watermarks
> --------------------------------------------------------
>
> Key: FLINK-7666
> URL: https://issues.apache.org/jira/browse/FLINK-7666
> Project: Flink
> Issue Type: Improvement
> Components: Streaming Connectors
> Affects Versions: 1.3.2
> Reporter: Ufuk Celebi
> Assignee: Kostas Kloudas
> Priority: Blocker
> Fix For: 1.4.0
>
>
> I use event time and read from a (finite) file. I assign watermarks right
> after the {{ContinuousFileReaderOperator}} with parallelism 1.
> {code}
> env
> .readFile(new TextInputFormat(...), ...)
> .setParallelism(1)
> .assignTimestampsAndWatermarks(...)
> .setParallelism(1)
> .map()...
> {code}
> The watermarks I assign never progress through the pipeline.
> I can work around this by inserting a {{shuffle()}} after the file reader or
> starting a new chain at the assigner:
> {code}
> env
> .readFile(new TextInputFormat(...), ...)
> .setParallelism(1)
> .shuffle()
> .assignTimestampsAndWatermarks(...)
> .setParallelism(1)
> .map()...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
