You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Aljoscha Krettek (JIRA)" <ji...@apache.org> on 2017/10/02 13:27:00 UTC
[jira] [Updated] (FLINK-6118) Chained operators forward watermark
without checking
[ https://issues.apache.org/jira/browse/FLINK-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aljoscha Krettek updated FLINK-6118:
------------------------------------
Description:
For operators that read from the network we have checks in place that verify that the input watermark only moves forwards. If an operator is directly chained to an operator then any {{Output.emitWatermark()}} of the first operator directly invoke {{processWatermark()}} on the chained operator, meaning that there are no verification steps in-between.
This only becomes visible when a non-keyed, chained operator (with, for example a {{ProcessFunction}}) is checking the current watermark. Only keyed operators can have timers and for those the watermark always comes form the network, i.e. it behaves correctly.
was:
For operators that read from the network we have checks in place that verify that the input watermark only moves forwards. If an operator is directly chained to an operator then any {{Output.emitWatermark()}} of the first operator directly invoke {{processWatermark()}} on the chained operator, meaning that there are no verification steps in-between.
This only becomes visible when a non-keyed, chained operator is checking the current operator. Only keyed operators can have timers and for those the watermark always comes form the network, i.e. it behaves correctly.
> Chained operators forward watermark without checking
> ----------------------------------------------------
>
> Key: FLINK-6118
> URL: https://issues.apache.org/jira/browse/FLINK-6118
> Project: Flink
> Issue Type: Bug
> Components: DataStream API
> Affects Versions: 1.2.0, 1.1.4, 1.3.0
> Reporter: Aljoscha Krettek
>
> For operators that read from the network we have checks in place that verify that the input watermark only moves forwards. If an operator is directly chained to an operator then any {{Output.emitWatermark()}} of the first operator directly invoke {{processWatermark()}} on the chained operator, meaning that there are no verification steps in-between.
> This only becomes visible when a non-keyed, chained operator (with, for example a {{ProcessFunction}}) is checking the current watermark. Only keyed operators can have timers and for those the watermark always comes form the network, i.e. it behaves correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)