Extending StreamExecutionEnvironment

["Matthias J. Sax" <mj...@informatik.hu-berlin.de>]

Hi,

currently, StreamExecutionEnvironment runs programs in a blocking
fashion, ie, it expects a job to finish by itself. However, streaming
jobs might run infinitely.

With the upcoming STOP signal, I would recommend to extend
StreamExecutionEnvironment such that a job can be executed in a detached
fashion and a method "stop(JobID)" that allows to stop the execution. We
might also include "cancel(JobID)".

What do you think?

There are a few design question about this, too:
 - overload execute() or introduce executeDetached()
 - should stop()/cancel() be blocking (with timeout?) or not (or both
should be possible)


-Matthias

Re: Extending StreamExecutionEnvironment

[Stephan Ewen <se...@apache.org>]

There is already an issue for this:
https://issues.apache.org/jira/browse/FLINK-2313

Before addressing this, I would like to merge
https://github.com/apache/flink/pull/858 , because the poll request also
touches the Client that communicates with the JobManager.

On Thu, Jul 16, 2015 at 3:38 PM, Matthias J. Sax <
mjsax@informatik.hu-berlin.de> wrote:

> Hi,
>
> currently, StreamExecutionEnvironment runs programs in a blocking
> fashion, ie, it expects a job to finish by itself. However, streaming
> jobs might run infinitely.
>
> With the upcoming STOP signal, I would recommend to extend
> StreamExecutionEnvironment such that a job can be executed in a detached
> fashion and a method "stop(JobID)" that allows to stop the execution. We
> might also include "cancel(JobID)".
>
> What do you think?
>
> There are a few design question about this, too:
>  - overload execute() or introduce executeDetached()
>  - should stop()/cancel() be blocking (with timeout?) or not (or both
> should be possible)
>
>
> -Matthias
>
>