[jira] [Created] (FLINK-4006) ExecutionGraph.restartStrategy field can't be serialized

ZhengBowen created FLINK-4006: - Summary: ExecutionGraph.restartStrategy field can't be serialized Key: FLINK-4006 URL: https://issues.apache.org/jira/browse/FLINK-4006 Project: Flink Issue Type:

[jira] [Created] (FLINK-4005) LocalExecutorITCase.testLocalExecutorWithWordCount fails

Ufuk Celebi created FLINK-4005: -- Summary: LocalExecutorITCase.testLocalExecutorWithWordCount fails Key: FLINK-4005 URL: https://issues.apache.org/jira/browse/FLINK-4005 Project: Flink Issue

Re: [PROPOSAL] Structure the Flink Open Source Development

Is "Observer" too passive? Maintainer -> Guide and/or Shepherd -> Reviewer? Are the component leads the first name in each list? If so, +1 from me :) On Wed, Jun 1, 2016 at 1:59 PM, Chesnay Schepler wrote: > sounds like "Observer" would fit. > > > On 01.06.2016 19:11,

[jira] [Created] (FLINK-4004) Do not pass custom flink kafka connector properties to Kafka to avoid warnings

Robert Metzger created FLINK-4004: - Summary: Do not pass custom flink kafka connector properties to Kafka to avoid warnings Key: FLINK-4004 URL: https://issues.apache.org/jira/browse/FLINK-4004

Re: [PROPOSAL] Structure the Flink Open Source Development

sounds like "Observer" would fit. On 01.06.2016 19:11, Fabian Hueske wrote: I think calling the role maintainer is not a good idea. The Spark community had a maintainer process which they just voted to remove. From my understanding, a maintainer in Spark had a more active role than the role we

Re: [PROPOSAL] Structure the Flink Open Source Development

I think calling the role maintainer is not a good idea. The Spark community had a maintainer process which they just voted to remove. From my understanding, a maintainer in Spark had a more active role than the role we are currently discussing. I would prefer to not call the role "maintainer" to

[jira] [Created] (FLINK-4003) Use intrinsics for MathUtils logarithms

Greg Hogan created FLINK-4003: - Summary: Use intrinsics for MathUtils logarithms Key: FLINK-4003 URL: https://issues.apache.org/jira/browse/FLINK-4003 Project: Flink Issue Type: Improvement

Re: Client communication and akka.framesize

Hi Felix, I don't think this PR will go in any time soon. Transferring data back to the client is not a very efficient anyways. Perhaps you could re-formulate your problem in a different way? Adjusting the framesize could also be an option:

Client communication and akka.framesize

Hi, we were running into the same problem that was described here[0] and are wondering if anyone is still working on/interested in this PR[1]. It would be great if this could be merged since we are collecting and distributing data of unknown sizes at the time of configuration and this leads

Re: HA Cluster restart behaviour

At the moment, the stop-cluster script simply sends a TERM signal to all processes using "kill". Shutting down the cluster cleanly is a bit more complicated and would block for a longer time. I think the current approach is the safest for most users. I agree that it would be nice to have an option

Re: HA Cluster restart behaviour

So you mean that you don't want people accidentally remove all jobs by shutting down the cluster? I think it is a bigger risk that people will actually click the cancel button on the website by accident :D For me it would seem intuitive that when I stop the cluster it stops the jobs. Definitely a

Re: HA Cluster restart behaviour

I also think that the current mechanism is weird. IMHO it makes sense to add the flag to both the start and stop scripts. On Wed, Jun 1, 2016 at 2:09 PM, Ufuk Celebi wrote: > Yes, it's expected, but you are certainly not the first one to be > confused by this behaviour. > > The

Re: HA Cluster restart behaviour

Yes, it's expected, but you are certainly not the first one to be confused by this behaviour. The reasoning behind the current behaviour is that we don't users accidentally removing jobs, which seems worse than requiring users to cancel manually. We thought about adding a flag to the start

HA Cluster restart behaviour

Hi, I have noticed some strange behaviour on a streaming cluster running in HA mode. I have stopped a cluster with some deployed jobs (stop-cluster.sh without cancelling the jobs) and when I bring the cluster back up the jobs that were running before are restarted. Is this the expected

Re: baseurl not overridden in documentation's Jekyll serve for local previewing

Hey Tzu-Li! Which commit are you referring to exactly? We just changed something yesterday and the build docs command now makes sure to use a specific Jekyll version via Rubygems. The Jekyll version we use is 2.5.3. And with this it works as expected for me. Previously, we had issues with

baseurl not overridden in documentation's Jekyll serve for local previewing

Hi all, Small problem here regarding locally previewing documentation using Jekyll serve. When the -p flag is used on docs/build_docs.sh for a local server to preview documentation, the intended behaviour of Jekyll is to override the baseurl setting in the main config docs/_config.yml with an

Re: [PROPOSAL] Structure the Flink Open Source Development

Btw, in Jira, if we clean up our components we can also set a component Lead that would get notified of issues for that component. On Wed, 1 Jun 2016 at 10:43 Chesnay Schepler wrote: > I'd also go with maintainer. > > On 01.06.2016 10:32, Aljoscha Krettek wrote: > > Hi, > >

Re: [PROPOSAL] Structure the Flink Open Source Development

I'd also go with maintainer. On 01.06.2016 10:32, Aljoscha Krettek wrote: Hi, I think maintainer is also fine if we clearly specify that they are not meant as dictators or gatekeepers of the component that they are responsible for. -Aljoscha On Wed, 1 Jun 2016 at 09:48 Vasiliki Kalavri

Re: [PROPOSAL] Structure the Flink Open Source Development

Hi, I think maintainer is also fine if we clearly specify that they are not meant as dictators or gatekeepers of the component that they are responsible for. -Aljoscha On Wed, 1 Jun 2016 at 09:48 Vasiliki Kalavri wrote: > Hi, > > we could go for something like

Re: [PROPOSAL] Structure the Flink Open Source Development

Hi, we could go for something like "sponsor" or "champion" :) I'm fine with the proposal. Good to see more than 1 person for both Gelly and Table API. cheers, -V. On 1 June 2016 at 05:46, Tzu-Li (Gordon) Tai wrote: > I'd like to be added to the Streaming Connectors