[
https://issues.apache.org/jira/browse/FLINK-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14532638#comment-14532638
]
ASF GitHub Bot commented on FLINK-1977:
---------------------------------------
Github user rmetzger commented on a diff in the pull request:
https://github.com/apache/flink/pull/659#discussion_r29852424
--- Diff:
flink-staging/flink-streaming/flink-streaming-core/src/main/java/org/apache/flink/streaming/api/functions/source/FileSourceFunction.java
---
@@ -46,39 +51,25 @@ public FileSourceFunction(InputFormat<String, ?>
format, TypeInformation<String>
}
@Override
+ @SuppressWarnings("unchecked")
public void open(Configuration parameters) throws Exception {
StreamingRuntimeContext context = (StreamingRuntimeContext)
getRuntimeContext();
this.provider = context.getInputSplitProvider();
inputFormat.configure(context.getTaskStubParameters());
+ serializer =
typeInfo.createSerializer(getRuntimeContext().getExecutionConfig());
--- End diff --
As far as I understand the streaming code, the execution config at runtime
is always invalid.
When running a streaming job, you'll get plenty of error messages like this:
```
11:26:25,600 WARN
org.apache.flink.runtime.jobgraph.tasks.AbstractInvokable - Environment did
not contain an ExecutionConfig - using a default config.
```
I was told that Streaming doesn't need the EC at runtime because all
serializers are created at the client and then send over serialized.
> Rework Stream Operators to always be push based
> -----------------------------------------------
>
> Key: FLINK-1977
> URL: https://issues.apache.org/jira/browse/FLINK-1977
> Project: Flink
> Issue Type: Improvement
> Reporter: Aljoscha Krettek
> Assignee: Aljoscha Krettek
>
> This is a result of the discussion on the mailing list. This is an excerpt
> from the mailing list that gives the basic idea of the change:
> I propose to change all streaming operators to be push based, with a
> slightly improved interface: In addition to collect(), which I would
> call receiveElement() I would add receivePunctuation() and
> receiveBarrier(). The first operator in the chain would also get data
> from the outside invokable that reads from the input iterator and
> calls receiveElement() for the first operator in a chain.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
