Re: [DISCUSS] Releasing Flink 1.1.4

The last fixes are finally in. Thanks to everyone who participated in the discussion. I will now create the release artifacts and start the vote tomorrow (CET). – Ufuk On 8 November 2016 at 19:02:46, Stephan Ewen (se...@apache.org) wrote: > I opened a pull request for the backport of [FLINK-490

Re: [DISCUSS] Releasing Flink 1.1.4

I opened a pull request for the backport of [FLINK-4904] https://github.com/apache/flink/pull/2773 On Tue, Nov 8, 2016 at 2:00 PM, Stephan Ewen wrote: > The issue FLINK-4904 (Add a limit for how much data may be spilled in > checkpoint alignme

Re: [DISCUSS] Releasing Flink 1.1.4

The issue FLINK-4904 (Add a limit for how much data may be spilled in checkpoint alignments) is doen for master and I am currently backporting it. Hope to finish that this week... Stephan On Wed, Nov 2, 2016 at 5:03 PM, Till Rohrmann wrote: > It might make sense to backport > > - [FLINK-4944]

Re: [DISCUSS] Releasing Flink 1.1.4

It might make sense to backport - [FLINK-4944] Replace Akka's death watch with own heartbeat on the TM side: https://github.com/apache/flink/pull/2742 as well. This will allow us to activate the quarantine monitoring per default in 1.1.4 without risking to kill all TMs in case of a JM failure. C

Re: [DISCUSS] Releasing Flink 1.1.4

As a quick update: the "pending review" issues have all been resolved. The open issues are still open: - FLINK-4904: Add a limit for how much data may be spilled in checkpoint alignments => fix pending - FLINK-4910: Introduce safety net for closing file system streams Any updates here? – Ufuk

Re: [DISCUSS] Releasing Flink 1.1.4

Benefit of a backport, as I see it, is increased stability. The danger is potentially breaking some code that was casting FileSystems to subtypes like LocalFileSytem. I don’t know how common that would be in user code. > Am 28.10.2016 um 14:27 schrieb Ufuk Celebi : > > Thanks for all your feed

Re: [DISCUSS] Releasing Flink 1.1.4

Thanks for all your feedback. If there are no objections, I would like to stick to the mentioned issues in this thread and create RC1 as soon as they are all addressed. This will probably not be this week though, but it looks good for next week. DONE = - FLINK-4619: Answer client if savepoint

Re: [DISCUSS] Releasing Flink 1.1.4

+1 for this release, also +1 to Chesnay's suggesting for including this: [FLINK-4875] [metrics] Use correct operator name Dan On Wed, Oct 26, 2016 at 5:06 AM Till Rohrmann wrote: > I'll work on FLINK-3347. Additionally I would like to get in > > - https://issues.apache.org/jira/browse/FLINK-493

Re: [DISCUSS] Releasing Flink 1.1.4

I'll work on FLINK-3347. Additionally I would like to get in - https://issues.apache.org/jira/browse/FLINK-4932: Don't let ExecutionGraph fail when in state Restarting - https://issues.apache.org/jira/browse/FLINK-4933: ExecutionGraph.scheduleOrUpdateConsumers can fail the ExecutionGraph Cheers,

Re: [DISCUSS] Releasing Flink 1.1.4

I think changes in behaviour should be limited to the case of streams that obtained from FileSystem within a task's main thread (or any of its child threads) and are also still used after that task finished. > Am 26.10.2016 um 13:02 schrieb Stephan Ewen : > > Concerning backporting the "I/O str

Re: [DISCUSS] Releasing Flink 1.1.4

Concerning backporting the "I/O streams safety net" - we need to make sure that this does not change any behavior that users may implicitly expect. On Wed, Oct 26, 2016 at 11:21 AM, Maximilian Michels wrote: > +1 for a 1.1.4 release > > We could backport putting user jars into the system class

Re: [DISCUSS] Releasing Flink 1.1.4

+1 for a 1.1.4 release We could backport putting user jars into the system class loader for per-job Yarn clusters: https://github.com/apache/flink/pull/2692 Arguably, this is somewhat a new feature but it gets rid of duplicate class loading issues users experienced in practice. We already have th

Re: [DISCUSS] Releasing Flink 1.1.4

+1 I think it could make sense to backport my safety net PR https://github.com/apache/flink/pull/2691for 1.1.4. The changes are pretty much isolated and it could help a lot about resource leaks and task cancelation times. Best, Stefan > Am 26.10

Re: [DISCUSS] Releasing Flink 1.1.4

+1 Looking forward this release ! Regards JB ⁣​ On Oct 25, 2016, 14:43, at 14:43, Robert Metzger wrote: >+1 for a bugfix release soon. > >On Tue, Oct 25, 2016 at 10:53 AM, Stephan Ewen >wrote: > >> Thanks fort starting this Ufuk. >> >> I would like to add the following issues to 1.1.4: >> >>

Re: [DISCUSS] Releasing Flink 1.1.4

I've added the following fix to the 1.1 branch * [FLINK-4875] [metrics] Use correct operator name It is a crucial fix for streaming topologies that involve multi-chains. 2 users already ran into this. On 25.10.2016 14:43, Robert Metzger wrote: +1 for a bugfix release soon. On Tue, Oct 25, 20

Re: [DISCUSS] Releasing Flink 1.1.4

+1 for a bugfix release soon. On Tue, Oct 25, 2016 at 10:53 AM, Stephan Ewen wrote: > Thanks fort starting this Ufuk. > > I would like to add the following issues to 1.1.4: > > Build errors due to Storm dependencies *(fix pending)* > - [FLINK-4298] [storm compatibility] Add proper repository

Re: [DISCUSS] Releasing Flink 1.1.4

Thanks fort starting this Ufuk. I would like to add the following issues to 1.1.4: Build errors due to Storm dependencies *(fix pending)* - [FLINK-4298] [storm compatibility] Add proper repository for Closure dependencies. Stability on S3 considering eventual consistency *(fix pending)*

[DISCUSS] Releasing Flink 1.1.4

Hey all, I would like to start the discussion for kicking off the next bug fix release, Flink 1.1.4. What do you think about aiming for a RC by end of this week? Users reported some instabilities/inconveniences that would be good to fix. Personally, I would like to backport the following fixes: