You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Stephan Ewen <se...@apache.org> on 2015/03/23 10:44:15 UTC
Tests for the Steaming classes
Hi everyone!
With the streaming stuff getting heavier exposure, I think it needs a few
more tests. With so many changes, untested features are running a high risk
of being "patched away" by accident.
For the runtime and batch API part, we go with the policy that every new
feature can only be merged is properly backed by tests. The streaming API
should now follow the same paradigm, in my opinion.
Here are some tests that I suggest to add
1) Settings/Configuration properly forwarded from ExecutionEnvironment to
JobGraph
2) Isolated tests for heavy and critical utilities (like barrier buffer)
3) Tests on the behavior of the abstract streaming vertex. Checks that
- RuntimeContext is porperly initialized
- open() and close() is always called (on RichFunctions)
- cancelling
- close() is called when cancelling a job()
- forwarding of barriers
4) Tests for the JobGraph construction
- parallelism properly configured
- connections and partitioners properly set
5) Tests for the chaining construction
- functions that can be chained and that cannot be chained
- chaining should not be affected by parallelism settings
Do you agree? Should I open a series of JIRAs for this?
Greetings,
Stephan
Re: Tests for the Steaming classes
Posted by Stephan Ewen <se...@apache.org>.
I am currently travelling, I'll open the JIRAs as soon as I find a bit of
time to sit down...
On Mon, Mar 23, 2015 at 5:20 PM, Henry Saputra <he...@gmail.com>
wrote:
> +1 for more tests and plus more documentation both internal and javadoc.
> Some stuff like memory usafe and data flows are bit different from batch
> which have not been documented much.
>
> Looks like more will be coming to Flink to check out streaming solution in
> Flink as alternative to others.
>
> - Henry
>
> On Monday, March 23, 2015, Stephan Ewen <se...@apache.org> wrote:
>
> > Hi everyone!
> >
> > With the streaming stuff getting heavier exposure, I think it needs a few
> > more tests. With so many changes, untested features are running a high
> risk
> > of being "patched away" by accident.
> >
> > For the runtime and batch API part, we go with the policy that every new
> > feature can only be merged is properly backed by tests. The streaming API
> > should now follow the same paradigm, in my opinion.
> >
> > Here are some tests that I suggest to add
> >
> > 1) Settings/Configuration properly forwarded from ExecutionEnvironment to
> > JobGraph
> >
> > 2) Isolated tests for heavy and critical utilities (like barrier buffer)
> >
> > 3) Tests on the behavior of the abstract streaming vertex. Checks that
> > - RuntimeContext is porperly initialized
> > - open() and close() is always called (on RichFunctions)
> > - cancelling
> > - close() is called when cancelling a job()
> > - forwarding of barriers
> >
> > 4) Tests for the JobGraph construction
> > - parallelism properly configured
> > - connections and partitioners properly set
> >
> > 5) Tests for the chaining construction
> > - functions that can be chained and that cannot be chained
> > - chaining should not be affected by parallelism settings
> >
> > Do you agree? Should I open a series of JIRAs for this?
> >
> > Greetings,
> > Stephan
> >
>
Re: Tests for the Steaming classes
Posted by Henry Saputra <he...@gmail.com>.
+1 for more tests and plus more documentation both internal and javadoc.
Some stuff like memory usafe and data flows are bit different from batch
which have not been documented much.
Looks like more will be coming to Flink to check out streaming solution in
Flink as alternative to others.
- Henry
On Monday, March 23, 2015, Stephan Ewen <se...@apache.org> wrote:
> Hi everyone!
>
> With the streaming stuff getting heavier exposure, I think it needs a few
> more tests. With so many changes, untested features are running a high risk
> of being "patched away" by accident.
>
> For the runtime and batch API part, we go with the policy that every new
> feature can only be merged is properly backed by tests. The streaming API
> should now follow the same paradigm, in my opinion.
>
> Here are some tests that I suggest to add
>
> 1) Settings/Configuration properly forwarded from ExecutionEnvironment to
> JobGraph
>
> 2) Isolated tests for heavy and critical utilities (like barrier buffer)
>
> 3) Tests on the behavior of the abstract streaming vertex. Checks that
> - RuntimeContext is porperly initialized
> - open() and close() is always called (on RichFunctions)
> - cancelling
> - close() is called when cancelling a job()
> - forwarding of barriers
>
> 4) Tests for the JobGraph construction
> - parallelism properly configured
> - connections and partitioners properly set
>
> 5) Tests for the chaining construction
> - functions that can be chained and that cannot be chained
> - chaining should not be affected by parallelism settings
>
> Do you agree? Should I open a series of JIRAs for this?
>
> Greetings,
> Stephan
>
Re: Tests for the Steaming classes
Posted by Gyula Fóra <gy...@apache.org>.
+1 for lots of streaming tests
On Mon, Mar 23, 2015 at 11:23 AM, Márton Balassi <ba...@gmail.com>
wrote:
> Thanks for looking into this, Stephan. +1 for the JIRAs.
>
> On Mon, Mar 23, 2015 at 10:55 AM, Ufuk Celebi <uc...@apache.org> wrote:
>
> > On 23 Mar 2015, at 10:44, Stephan Ewen <se...@apache.org> wrote:
> >
> > > Hi everyone!
> > >
> > > With the streaming stuff getting heavier exposure, I think it needs a
> few
> > > more tests. With so many changes, untested features are running a high
> > risk
> > > of being "patched away" by accident.
> > >
> > > For the runtime and batch API part, we go with the policy that every
> new
> > > feature can only be merged is properly backed by tests. The streaming
> API
> > > should now follow the same paradigm, in my opinion.
> > >
> > > Here are some tests that I suggest to add
> > >
> > > 1) Settings/Configuration properly forwarded from ExecutionEnvironment
> to
> > > JobGraph
> > >
> > > 2) Isolated tests for heavy and critical utilities (like barrier
> buffer)
> > >
> > > 3) Tests on the behavior of the abstract streaming vertex. Checks that
> > > - RuntimeContext is porperly initialized
> > > - open() and close() is always called (on RichFunctions)
> > > - cancelling
> > > - close() is called when cancelling a job()
> > > - forwarding of barriers
> > >
> > > 4) Tests for the JobGraph construction
> > > - parallelism properly configured
> > > - connections and partitioners properly set
> > >
> > > 5) Tests for the chaining construction
> > > - functions that can be chained and that cannot be chained
> > > - chaining should not be affected by parallelism settings
> > >
> > > Do you agree? Should I open a series of JIRAs for this?
> >
> > I agree with your assessment. +1 to open the respective issues to track
> > this.
> >
>
Re: Tests for the Steaming classes
Posted by Márton Balassi <ba...@gmail.com>.
Thanks for looking into this, Stephan. +1 for the JIRAs.
On Mon, Mar 23, 2015 at 10:55 AM, Ufuk Celebi <uc...@apache.org> wrote:
> On 23 Mar 2015, at 10:44, Stephan Ewen <se...@apache.org> wrote:
>
> > Hi everyone!
> >
> > With the streaming stuff getting heavier exposure, I think it needs a few
> > more tests. With so many changes, untested features are running a high
> risk
> > of being "patched away" by accident.
> >
> > For the runtime and batch API part, we go with the policy that every new
> > feature can only be merged is properly backed by tests. The streaming API
> > should now follow the same paradigm, in my opinion.
> >
> > Here are some tests that I suggest to add
> >
> > 1) Settings/Configuration properly forwarded from ExecutionEnvironment to
> > JobGraph
> >
> > 2) Isolated tests for heavy and critical utilities (like barrier buffer)
> >
> > 3) Tests on the behavior of the abstract streaming vertex. Checks that
> > - RuntimeContext is porperly initialized
> > - open() and close() is always called (on RichFunctions)
> > - cancelling
> > - close() is called when cancelling a job()
> > - forwarding of barriers
> >
> > 4) Tests for the JobGraph construction
> > - parallelism properly configured
> > - connections and partitioners properly set
> >
> > 5) Tests for the chaining construction
> > - functions that can be chained and that cannot be chained
> > - chaining should not be affected by parallelism settings
> >
> > Do you agree? Should I open a series of JIRAs for this?
>
> I agree with your assessment. +1 to open the respective issues to track
> this.
>
Re: Tests for the Steaming classes
Posted by Ufuk Celebi <uc...@apache.org>.
On 23 Mar 2015, at 10:44, Stephan Ewen <se...@apache.org> wrote:
> Hi everyone!
>
> With the streaming stuff getting heavier exposure, I think it needs a few
> more tests. With so many changes, untested features are running a high risk
> of being "patched away" by accident.
>
> For the runtime and batch API part, we go with the policy that every new
> feature can only be merged is properly backed by tests. The streaming API
> should now follow the same paradigm, in my opinion.
>
> Here are some tests that I suggest to add
>
> 1) Settings/Configuration properly forwarded from ExecutionEnvironment to
> JobGraph
>
> 2) Isolated tests for heavy and critical utilities (like barrier buffer)
>
> 3) Tests on the behavior of the abstract streaming vertex. Checks that
> - RuntimeContext is porperly initialized
> - open() and close() is always called (on RichFunctions)
> - cancelling
> - close() is called when cancelling a job()
> - forwarding of barriers
>
> 4) Tests for the JobGraph construction
> - parallelism properly configured
> - connections and partitioners properly set
>
> 5) Tests for the chaining construction
> - functions that can be chained and that cannot be chained
> - chaining should not be affected by parallelism settings
>
> Do you agree? Should I open a series of JIRAs for this?
I agree with your assessment. +1 to open the respective issues to track this.