[
https://issues.apache.org/jira/browse/FLINK-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15548994#comment-15548994
]
ASF GitHub Bot commented on FLINK-4329:
---------------------------------------
Github user StephanEwen commented on a diff in the pull request:
https://github.com/apache/flink/pull/2593#discussion_r81990874
--- Diff:
flink-streaming-java/src/main/java/org/apache/flink/streaming/api/operators/StreamSource.java
---
@@ -214,14 +216,26 @@ public AutomaticWatermarkContext(
this.watermarkInterval = watermarkInterval;
this.reuse = new StreamRecord<T>(null);
+ // if it is a source, then we cast and cache it
+ // here so that we do not have to do it in every
collect(),
+ // collectWithTimestamp() and emitWatermark()
+
+ if (!(owner instanceof AsyncExceptionChecker)) {
+ throw new IllegalStateException("The
ManualWatermarkContext can only be used " +
+ "with sources that implement the
AsyncExceptionChecker interface.");
+ }
+ this.source = (AsyncExceptionChecker) owner;
+
long now = owner.getCurrentProcessingTime();
this.watermarkTimer = owner.registerTimer(now +
watermarkInterval,
new WatermarkEmittingTask(owner,
lockingObjectParam, outputParam));
}
@Override
public void collect(T element) {
- owner.checkAsyncException();
+ if (source != null) {
--- End diff --
source can never be null?
> Fix Streaming File Source Timestamps/Watermarks Handling
> --------------------------------------------------------
>
> Key: FLINK-4329
> URL: https://issues.apache.org/jira/browse/FLINK-4329
> Project: Flink
> Issue Type: Bug
> Components: Streaming Connectors
> Affects Versions: 1.1.0
> Reporter: Aljoscha Krettek
> Assignee: Kostas Kloudas
> Fix For: 1.2.0, 1.1.3
>
>
> The {{ContinuousFileReaderOperator}} does not correctly deal with watermarks,
> i.e. they are just passed through. This means that when the
> {{ContinuousFileMonitoringFunction}} closes and emits a {{Long.MAX_VALUE}}
> that watermark can "overtake" the records that are to be emitted in the
> {{ContinuousFileReaderOperator}}. Together with the new "allowed lateness"
> setting in window operator this can lead to elements being dropped as late.
> Also, {{ContinuousFileReaderOperator}} does not correctly assign ingestion
> timestamps since it is not technically a source but looks like one to the
> user.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
