Re: [VOTE] FLIP-110: Support LIKE clause in CREATE TABLE

+1 Aljoscha

Re: [DISCUSS]FLIP-113: Support SQL and planner hints

at do you think? Regards, Timo On 02.04.20 16:24, Aljoscha Krettek wrote: I think we're designing ourselves into ever more complicated corners here. Maybe we need to take a step back and reconsider. What would you think about this (somewhat) simpler proposal: - introduce a hint called C

Re: [DISCUSS] FLIP-124: Add open/close and Collector to (De)SerializationSchema

On 07.04.20 08:45, Dawid Wysakowicz wrote: @Jark I was aware of the implementation of SinkFunction, but it was a conscious choice to not do it that way. Personally I am against giving a default implementation to both the new and old methods. This results in an interface that by default does not

Re: [DISCUSS]FLIP-113: Support SQL and planner hints

On 08.04.20 04:27, Jark Wu wrote: I have a minor concern about the global configuration `table.optimizer.dynamic-table-options.enabled`, does it belong to optimizer? From my point of view, it is just an API to set table options and uses Calcite in the implementation. I'm also thinking about wha

[PSA] Please check your github email configuration when merging on Github

Hi Everyone, we have a lot of commits recently that were committed by "GitHub ". This happens when your GitHub account is not configured correctly with respect to your email address. Please make sure that your commits somehow show who is the committer. For reference, check out https://help.

Re: Configuring autolinks to Flink JIRA ticket in github repos

That is very nice! Thanks for taking care of this ~3q On 09.04.20 11:08, Dian Fu wrote: Cool! Thanks Yun for this effort. Very useful feature. Regards, Dian 在 2020年4月9日，下午4:32，Yu Li 写道： Great! Thanks for the efforts Yun. Best Regards, Yu On Thu, 9 Apr 2020 at 16:15, Jark Wu wrote: Tha

Re: [DISCUSS] FLIP-124: Add open/close and Collector to (De)SerializationSchema

On 10.04.20 17:35, Jark Wu wrote: 1) For correctness, it is necessary to perform the watermark generation as early as possible in order to be close to the actual data generation within a source's data partition. This is also the purpose of per-partition watermark and event-time alignment. Man

[DISCUSS] Releasing "fat" and "slim" Flink distributions

Hi Everyone, I'd like to discuss about releasing a more full-featured Flink distribution. The motivation is that there is friction for SQL/Table API users that want to use Table connectors which are not there in the current Flink Distribution. For these users the workflow is currently roughly

Re: [VOTE] FLIP-108: Add GPU support in Flink

Is the only really new method on the public APIs getExternalResourceInfos(..) on the RuntimeContext? I'm generally quite skeptical about adding anything to that interface but the method seems ok. Side note for the configuration keys: the pattern is similar to metrics configuration. There we ha

Re: [DISCUSS] Integration of training materials into Apache Flink

I'd be very happy if someone took over that part of the documentation! There are open issues for the TODOs in the concepts section here: https://issues.apache.org/jira/browse/FLINK-12639. But feel free to comment there/close/re-arrange as you see fit. Maybe we use this thread and Jira to coordi

Re: [DISCUSS] Releasing "fat" and "slim" Flink distributions

ally verbose when I prepare webinars. At least, I think the flink-csv and flink-json should in the distribution, they are quite small and don't have other dependencies. Best, Jark On Wed, 15 Apr 2020 at 15:44, Jeff Zhang wrote: Hi Aljoscha, Big +1 for the fat flink distribution, where

Re: [VOTE] FLIP-124: Add open/close and Collector to (De)SerializationSchema

+1 (binding) Aljoscha

Re: [PROPOSAL] Google Season of Docs 2020.

Hi, first, excellent that you're driving this, Marta! By now I have made quite some progress on the FLIP-42 restructuring so that is not a good effort for someone to join now. Plus there is also [1], which is about incorporating the existing Flink Training material into the concepts section o

Re: [DISCUSS] Releasing "fat" and "slim" Flink distributions

ot be chosen at the same time with kafka-universal etc. The benefit of it would be that the distribution that we release could remain "slim" or we could even make it slimmer. I might be missing something here though. Best, Dawdi On 16/04/2020 11:02, Aljoscha Krettek wrote: I want to

[DISCUSS] FLIP-126: Unify (and separate) Watermark Assigners

Hi Everyone! We would like to start a discussion on "FLIP-126: Unify (and separate) Watermark Assigners" [1]. This work was started by Stephan in an experimental branch. I expanded on that work to provide a PoC for the changes proposed in this FLIP: [2]. Currently, we have two different flav

Re: [DISCUSS] Adding support for Hadoop 3 and removing flink-shaded-hadoop

+1 to getting rid of flink-shaded-hadoop. But we need to document how people can now get a Flink dist that works with Hadoop. Currently, when you download the single shaded jar you immediately get support for submitting to YARN via bin/flink run. Aljoscha On 22.04.20 09:08, Till Rohrmann wro

Re: [DISCUSS] Exact feature freeze date

+1 Aljoscha On 23.04.20 15:23, Till Rohrmann wrote: +1 for extending the feature freeze until May 15th. Cheers, Till On Thu, Apr 23, 2020 at 1:00 PM Piotr Nowojski wrote: Hi Stephan, As release manager I’ve seen that quite a bit of features could use of the extra couple of weeks. This als

Re: [DISCUSS] Removing deprecated state methods in 1.11

Definitely +1! I'm always game for decreasing the API surface if it doesn't decrease functionality. Aljoscha On 23.04.20 14:18, DONG, Weike wrote: Hi Stephan, +1 for the removal, as there are so many deprecated methods scattered around, making APIs a little bit messy and confusing. Best, Wei

Re: [DISCUSS] Releasing "fat" and "slim" Flink distributions

more. (2) I can imagine there still being a desire to have a "minimal" docker file, for users that want to keep the container images as small as possible, to speed up deployment. It is fine if that would not be the default, though. On Fri, Apr 17, 2020 at 12:16 PM Aljoscha Krettek wr

Re: Multiple rebalances are incorrectly ignored in some cases.

On 27.04.20 09:34, David Morávek wrote: When we include `flatMap` in between rebalances -> `.rebalance().flatMap(...).rebalance()`, we need to reshuffle again, because dataset distribution may have changed (eg. you can possibli emit unbouded stream from a single element). Unfortunatelly `flatMap

Re: A query on codebase exploration

Hi Manish, welcome to the community! You could start from a user program example and then try and figure out how that leads to job execution. So probably start with the DataStream WordCount example, figure out what the methods on DataStream do, that is how they build up a graph of Transformati

Re: [DISCUSS] Intermediary releases of the flink-docker images

Hi Niels, I think Robert was referring to the fact that Apache considers only the source release to be "the release", everything else is called convenience release. Best, Aljoscha On 27.04.20 19:43, Niels Basjes wrote: Hi, In my opinion the docker images are essentially simply differently

Re: [DISCUSS] FLIP-84 Feedback Summary

MultilineSql`, I'm afraid sometimes user might forget to iterate the returned iterators, e.g. user submits a bunch of DDLs and expect the framework will execute them one by one. But it didn't. Best, Kurt On Wed, Apr 1, 2020 at 5:10 PM Aljoscha Krettek< aljos...@apache.org>

Re: [DISCUSS] FLIP-126: Unify (and separate) Watermark Assigners

k forward to update to the new unified watermark generators once FLIP-126 has been accepted. Regards, Timo [1] https://github.com/apache/flink/pull/11692 On 20.04.20 18:10, Aljoscha Krettek wrote: Hi Everyone! We would like to start a discussion on "FLIP-126: Unify (and separate) Waterma

Re: [DISCUSS] flink-connector-rabbitmq api changes

Hi, I think it's good to contribute the changes to Flink directly since we already have the RMQ connector in the respository. I would propose something similar to the Kafka connector, which takes both the generic DeserializationSchema and a KafkaDeserializationSchema that is specific to Kafk

Re: [DISCUSS][FLIP-108] Problems regarding the class loader and dependency

I agree with Till and Xintong, if the ExternalResourceInfo is only a holder of properties that doesn't have any sublasses it can just become the "properties" itself. Aljoscha On 30.04.20 12:49, Till Rohrmann wrote: Thanks for the clarification. I think you are right that the typed approach d

Re: [DISCUSS] flink-connector-rabbitmq api changes

uot; as for the code i have it here in the PR: https://github.com/senegalo/flink/pull/1 it's not that much of a change in terms of logic but more of what is exposed. Let me know how you want me to proceed. Thanks again, Karim Mansour On Thu, Apr 30, 2020 at 10:40 AM Aljoscha Krettek ma

Re: [VOTE] Release 1.10.1, release candidate #2

Unfortunately, I found this bug which prevents the TaskCancelerWatchdog [sic] from working: https://issues.apache.org/jira/browse/FLINK-17514. I think it's quite crucial that this failsafe mechanism works correctly. We should cancel the release and fix it. Best, Aljoscha On 05.05.20 05:55, He

Re: [DISCUSS] Releasing "fat" and "slim" Flink distributions

Young wrote: +1 for "slim" and "fat" solution. One comment about the fat one, I think we need to put all needed jars into /lib (or /plugins). Put jars into /opt and relying on users moving them from /opt to /lib doesn't really improve the out-of-box experience. Best,

Re: [DISCUSS] Introduce The Batch/Stream ExecutionEnvironment in Yarn mode

Hi, image attachments don't work on this ML. You will have to upload the image somewhere and post a link. Best, Aljoscha On 02.05.20 09:16, Jeff Zhang wrote: Hi Roc, You can try flink on zeppelin, where you can submit flink job to yarn directly without starting flink cluster by yourself. H

Re: [DISCUSS] Releasing "fat" and "slim" Flink distributions

ion a separate release because of potential dependency conflicts for users who don't want to use SQL. Cheers, Till On Tue, May 5, 2020 at 10:01 AM Aljoscha Krettek wrote: Thanks Till for summarizing! Another alternative is also to stick to one distribution but remove one of the very heavy

Re: [DISCUSS] Introduce The Batch/Stream ExecutionEnvironment in Yarn mode

Could you post the Jira issue here? I don't see it mentioned in this thread so far. Best, Aljoscha On 05.05.20 12:32, Roc Marshal wrote: Hi,Aljoscha.I have updated the JIRA according to your suggestion. Thank you very much.Best,Roc At 2020-05-05 16:04:01, "Aljoscha Krettek&qu

Re: [DISCUSS] FLIP-126: Unify (and separate) Watermark Assigners

y compelling case. On Wed, Apr 29, 2020 at 7:24 PM Aljoscha Krettek wrote: Regarding the WatermarkGenerator (WG) interface itself. The proposal is basically to turn emitting into a "flatMap", we give the WatermarkGenerator a "collector" (the WatermarkOutput) and the WG can

Re: [DISCUSS] FLIP-126: Unify (and separate) Watermark Assigners

newly added connector. I know that's a bit unorthodox but would everyone be OK with what's currently there and then we iterate? Best, Aljoscha On 11.05.20 13:57, Aljoscha Krettek wrote: Ah, I meant to write this in my previous email, sorry about that. The WatermarkStrategy, which

Re: What's the best practice to determine whether a job has finished or not?

Hi, The problem is that the JobClient is talking to the wrong system. In YARN per-job mode the cluster will only run as long as the job runs so there will be no-one there to respond with the job status after the job is finished. I think the solution is that the JobClient should talk to the righ

[VOTE] FLIP-126: FLIP-126: Unify (and separate) Watermark Assigners

Hi all, I would like to start the vote for FLIP-126 [1], which is discussed and reached a consensus in the discussion thread [2]. The vote will be open until May 15th (72h), unless there is an objection or not enough votes. Best, Aljoscha [1] https://cwiki.apache.org/confluence/display/FLINK

Re: [DISCUSS] FLIP-126: Unify (and separate) Watermark Assigners

eady (as Aljoscha mentioned via the factories) can extend this if needed. I think that the factory approach supports code-generated extractors in a cleaner way even than an extractor with an open/init method. On Mon, May 11, 2020 at 3:38 PM Aljoscha Krettek wrote: We're slightly run

Re: [DISCUSS] FLIP-126: Unify (and separate) Watermark Assigners

th cases (in-source-record timestamp, in stream-record timestamp). On Tue, May 12, 2020 at 4:12 PM Aljoscha Krettek wrote: Definitely +1 to point 2) raised by Dawid. I'm not sure on points 1) and 3). 1) I can see the benefit of that but in reality most timestamp assigners will probably need

[RESULT][VOTE] FLIP-126: FLIP-126: Unify (and separate) Watermark Assigners

iscussions about minor changes (names and serializability) pending, but these should not conflict with the design here. On Tue, May 12, 2020 at 10:01 AM Aljoscha Krettek wrote: Hi all, I would like to start the vote for FLIP-126 [1], which is discussed and reached a consensus in the discussion

Re: [DISCUSS] Semantics of our JIRA fields

+1 That's also how I think of the semantics of the fields. Aljoscha On 22.05.20 08:07, Robert Metzger wrote: Hi all, I have the feeling that the semantics of some of our JIRA fields (mostly "affects versions", "fix versions" and resolve / close) are not defined in the same way by all the core

Re: [DISCUSS] FLIP-126: Unify (and separate) Watermark Assigners

e... Best, Dawid On 12/05/2020 18:21, Aljoscha Krettek wrote: Yes, I am also ok with a SerializableTimestampAssigner. This only looks a bit clumsy in the API but as a user (that uses lambdas) you should not see this. I pushed changes for this to my branch: https://github.com/aljoscha/flink/tree

Re: [DISCUSS] Backpoint FLIP-126 (watermarks) integration with FLIP-27

+1 I'm in favour of backporting this because we otherwise would immediately break the API between 1.11 and 1.12. Best, Aljoscha On 26.05.20 17:05, Zhijiang wrote: In the beginning, I have somehow similar concerns as Piotr mentioned below. After some offline discussions, also as explained by

[DISCUSS] Update our EditorConfig file

Hi, is anyone actually using our .editorconfig file? IntelliJ has a plugin for this that is actually quite powerful. I managed to write a .editorconfig file that I quite like: https://github.com/aljoscha/flink/commits/new-editorconfig. For me to use that, we would either need to update our F

[DISCUSS] Re-renaming "Flink Master" back to JobManager

Hi All, This came to my mind because of the master/slave discussion in [1] and the larger discussions about inequality/civil rights happening right now in the world. I think for this reason alone we should use a name that does not include "master". We could rename it back to JobManager, whic

Re: [DISCUSS] Re-renaming "Flink Master" back to JobManager

seems doable. Best, Konstantin On Mon 15. Jun 2020 at 12:56, Aljoscha Krettek wrote: Hi All, This came to my mind because of the master/slave discussion in [1] and the larger discussions about inequality/civil rights happening right now in the world. I think for this reason alone we should use

[DISCUSS] Cross-version compatibility guarantees of Flink Modules/Jars

Hi, this has come up a few times now and I think we need to discuss the guarantees that we want to officially give for this. What I mean by cross-version compatibility is using, say, a Flink 1.10 Kafka connector dependency/jar with Flink 1.11, or a Flink 1.10.0 connector with Flink 1.10.1. In

Re: [DISCUSS] Cross-version compatibility guarantees of Flink Modules/Jars

yway. Cheers, Konstantin [] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Stability-guarantees-for-PublicEvolving-classes-tp41459.html On Tue, Jun 23, 2020 at 3:32 PM Aljoscha Krettek wrote: Hi, this has come up a few times now and I think we need to discuss the guarantees

Re: [DISCUSS] Cross-version compatibility guarantees of Flink Modules/Jars

ot burned in the past by having too much be @Public and forcing us to keep things around for longer than we wanted, but then we did a full 180 and stopped giving _any_ guarantees for all new APIs. It is about time we change this. On 24/06/2020 09:15, Aljoscha Krettek wrote: Yes, I would say the

Re: [ANNOUNCE] Apache Flink 1.11.0, release candidate #2

Hi! On 24.06.20 00:51, Thomas Weise wrote: * -import org.apache.flink.table.api.java.StreamTableEnvironment; +import org.apache.flink.table.api.bridge.java.StreamTableEnvironment; This is very unfortunate yes, please see https://github.com/apache/flink/pull/12699/files#diff-eaa874e007e88f2

Re: [DISCUSS] FLIP-128: Enhanced Fan Out for AWS Kinesis Consumers

Wow, that is one thorough FLIP! I didn't fully go into all the technical details but I think the general direction of this is good. If no one objects I'd say we can proceed to voting and figure out the technical details during implementation/review (if any remain unclear). Best, Aljoscha On 2

Re: [VOTE] FLIP-128: Enhanced Fan Out for AWS Kinesis Consumers

+1 Aljoscha On 01.07.20 15:14, Tzu-Li (Gordon) Tai wrote: +1 On Wed, Jul 1, 2020, 8:57 PM Cranmer, Danny wrote: Hi all, I'd like to start a voting thread for FLIP-128 [1], which we've reached consensus in [2]. This voting will be open for minimum 3 days till 13:00 UTC, July 4th. Thanks,

Re: [VOTE] Release 1.11.0, release candidate #4

+1 - verified hash of source release - verified signature of source release - source release compiles (with Scala 2.11) - examples run without spurious log output (errors, exceptions) I can confirm that log scrolling doesn't work on Firefox, though it never has. I would also feel better i

Re: [DISCUSS] Releasing Flink 1.11.1 soon?

+1 I'd also be in favour of releasing a 1.11.1 quickly Aljoscha On 09.07.20 13:57, Jark Wu wrote: Hi Dian, Glad to hear that you want to be the release manager of Flink 1.11.1. I am very willing to help you with the final steps of the release process. Best, Jark On Thu, 9 Jul 2020 at 17:57,

Re: Improvement idea: Naming the maven modules.

Hi, I like the proposal! I remember that Beam also had more human-readable names for the modules and found that helpful. Also, changing the names shouldn't change anything for users because dependencies are referred to by group/artifactId, it really just makes build output and IDE a bit more p

Re: Use of SinkFunction.Context without generic parameter.

Hi, this was actually my mistake back then. :-O I'm open to removing the generic parameter from Context if we are sure that it won't break user code. I think it doesn't, because you cannot actually use it with the generic parameter, as you found. Also, I think custom sink implementations in us

Re: [DISCUSS] FLIP-130: Support for Python DataStream API (Stateless Part)

Hi, thanks for the proposal! I have some comments about the API. We should not blindly copy the existing Java DataSteam because we made some mistakes with that and we now have a chance to fix them and not forward them to a new API. I don't think we need SingleOutputStreamOperator, in the Scala

Re: PackagedProgram and ProgramDescription

luding its parameters and types) in order to enable better UIs, then > the important thing is to make things consistent and aligned with the new > client developments and exploit this new dev sprint to fix such issues. > > On Mon, Mar 30, 2020 at 11:38 AM Aljoscha Krettek > wrote: >

Re: [REMINDER] Use 'starter' labels for Jira issues where it makes sense

Yes, thanks Andrey! That's a good reminder for everyone. :-) On 20.07.20 16:02, Andrey Zagrebin wrote: Hi Flink Devs, I would like to remind you that we have a 'starter' label [1] to annotate Jira issues which need a contribution and which are not very complicated for the new contributors. The

Re: Inconsistent behavior between different states with ListState.get().iterator().remove()

That is a very good observation! In an ideal world, I would say we disallow #remove() because we cannot efficiently implement it for RocksDB and we should keep the behaviour consistent between the backends. Now that we already have the functionality for the heap-based backends I think we canno

Re: [DISCUSS] FLIP-130: Support for Python DataStream API (Stateless Part)

Row. (I have updated the example section of the FLIP to reflect the design.) Highly appreciated for your suggestions again. Looking forward to your feedback. Best, Shuiqiang Aljoscha Krettek 于2020年7月15日周三 下午5:58写道： Hi, thanks for the proposal! I have some comments about the API. We sho

Re: [DISCUSS] FLIP-129: Refactor Descriptor API to register connector in Table API

I'm jumping in quite late but I think overall this is a very good effort and it's in very good shape now. Best, Aljoscha On 24.07.20 10:24, Jark Wu wrote: Thanks Dawid, Regarding (3), I think you mentioned it will affect other behavior, e.g. listing tables, is a strong reason. I will at least

Re: [DISCUSS] FLIP-130: Support for Python DataStream API (Stateless Part)

he Python DataStream implementation. And thank you all for joining in the discussion. It seems that we have reached a consensus. I will start a vote for this FLIP later today. Best, Shuiqiang Hequn Cheng 于2020年7月24日周五 下午5:29写道： Thanks a lot for your valuable feedback and suggestions! @Aljoscha Kret

Re: [VOTE] FLIP-130: Support for Python DataStream API (Stateless Part)

+1 (binding) Aljoscha On 28.07.20 04:12, Dian Fu wrote: Thanks for driving this Shuiqiang. +1 Regards, Dian 在 2020年7月27日，下午3:33，jincheng sun 写道： +1(binding) Best, Jincheng Shuiqiang Chen 于2020年7月24日周五 下午8:32写道： Hi everyone, I would like to start the vote for FLIP-130[1], which is di

[DISCUSS] FLIP-131: Consolidate the user-facing Dataflow SDKs/APIs (and deprecate the DataSet API)

Hi Everyone, my colleagues (in cc) and I would like to propose this FLIP for discussion. In short, we want to reduce the number of APIs that we have by deprecating the DataSet API. This is a big step for Flink, that's why I'm also cross-posting this to the User Mailing List. FLIP-131: http:/

Re: [DISCUSS] FLIP-131: Consolidate the user-facing Dataflow SDKs/APIs (and deprecate the DataSet API)

up and starting the discussion. I am in favor of unifying the APIs the way described in the FLIP and deprecating the DataSet API. I am looking forward to the detailed discussion of the changes necessary. Best, Marton On Wed, Jul 29, 2020 at 12:46 PM Aljoscha Krettek < aljos...@apache.org>

Re: [DISCUSS] FLIP-131: Consolidate the user-facing Dataflow SDKs/APIs (and deprecate the DataSet API)

ngle functional unit, just to make the code more modular.. It's very comfortable indeed. On Thu, Jul 30, 2020 at 5:20 PM Aljoscha Krettek wrote: That is good input! I was not aware that anyone was actually using `runCustomOperation()`. Out of curiosity, what are you using that for? We have

Re: Error with Flink-Gelly, lastJobExecutionResult is null

Thanks for the pointer! On 03.08.20 10:29, Till Rohrmann wrote: Hi Xia Rui, thanks for reporting this issue. I think FLINK-15116 [1] caused the regression. The problem is indeed that we no longer set the lastJobExecutionResult when using the ContextEnvironment. The problem has not surfaced sinc

Re: Switch to Scala 2.11 as a default build profile

+1 For changing the default. I think a lot of systems don’t even support 2.10 anymore. > On 28. Jun 2017, at 14:38, Ted Yu wrote: > > +1 on using Scale 2.11 as default. > Original message From: Piotr Nowojski > Date: 6/28/17 5:36 AM (GMT-08:00) To: > dev@flink.apache.org

Re: [DISCUSS] FLIP-21 - Improve object Copying/Reuse Mode for Streaming Runtime

+1 for changing the default if so many people encountered problems with serialisation costs. The first two modes don’t require any code changes, correct? Only the last one would require changes to the stream input processors. We should also keep this issue in mind: https://issues.apache.org/ji

Re: [DISCUSS] Release 1.3.2 planning

Gordon and I found this (in my opinion) blocking issue: https://issues.apache.org/jira/browse/FLINK-7041 I’m trying to quickly provide a fix. > On 26. Jun 2017, at 15:30, Timo Walther wrote: > > I just opened a PR which should be included in

Re: [DISCUSS] First release of flink-shaded

+1 Sounds good! I have followed the process on the various issues and the new shaded repository and the changes seem straightforward (more or less ;-)) > On 3. Jul 2017, at 14:32, Chesnay Schepler wrote: > > Hello, > > I would like to kick off the first release of flink-shaded. > > In the cu

Re: [DISCUSS] First release of flink-shaded

Is it even possible to shade Kryo with it being in the public API? I don’t think it is (without looking into this to deeply, though). > On 3. Jul 2017, at 17:23, Chesnay Schepler wrote: > > I would tackle Kryo later as it is exposed through the API > (StreamExecutionEnvironment#addDefaultKryoS

Re: [DISCUSS] First release of flink-shaded

following: > > import com.esotericsoftware.kryo.Serializer; > > I think shading is possible since we can declare the Serializer class to > come from shaded Kryo namespace. > > On Mon, Jul 3, 2017 at 9:25 AM, Aljoscha Krettek > wrote: > >> Is it even possible to sha

Re: Tips to fix IDEA strange problem after updating master code

Thanks for the hint! > On 4. Jul 2017, at 06:03, Ted Yu wrote: > > Looks like the picture didn't go thru. > > Mind using third party site ? > > Thanks > > On Mon, Jul 3, 2017 at 8:56 PM, Jark Wu wrote: > >> Hi devs, >> >> Yesterday, I updated the master code which include [FLINK-7030]: Bui

Re: refactor StreamConfig

I think the proposed changed are good, I just wanted to make sure that they don’t interfere with what other people are doing. I also proposed these steps on the Github PR: Also, for actually doing the changes I suggest separate steps, i.e. separate commits. With possibly separate PRs to make rev

Re: refactor StreamConfig

Hi, Yes, but I think what Stephan was hinting at was to change both of them to be serialisable when already working on this. I think input serialiser is fine to have in OperatorConfig, you’re right! I don’t see getChainIndex() used anywhere in the code, though. And the output edges and seriali

Re: connect data stream with parameter stream

Hi Lei, I’m afraid there is currently no API for doing this in one operation. I see two options right now: 1. Built a custom operator that implements windowing and also has a second input for the parameter stream. This would be a subclass of TwoInputStreamOperator. As an example, you can look

Re: [DISCUSS] Release 1.3.2 planning

> https://issues.apache.org/jira/browse/FLINK-6996. > > Cheers, > Gordon > On 30 June 2017 at 12:46:07 AM, Aljoscha Krettek (aljos...@apache.org) wrote: > > Gordon and I found this (in my opinion) blocking issue: > https://issues.apache.org/jira/browse/FLINK-7041 > &l

Re: [DISCUSS] Managing announcements of breaking API / state compatibility changes in major releases

+1 This sounds very good! I just hope that everyone is aware enough and doesn’t forget adding these tags. > On 6. Jul 2017, at 09:59, Tzu-Li (Gordon) Tai wrote: > > > Hi devs, > > I would like to follow up my proposal in [1] regarding how we can more > systematically and easily collect brea

Re: refactor StreamConfig

need to be serialized >> into the Configuration, which is underlying before and flows across modules. >> >> >> Do you agree what I understand? >> >> >> Best Regards! >> >> >> Xu Pingyong >> >> >> >> >> >> >>

Re: How to set jobmanager.rpc.address in TaskManger node in HA cluster

Cool, thanks for letting us know that you figured it out and what it was! > On 7. Jul 2017, at 05:52, Mu Kong wrote: > > Sorry. I didn't put high-availability: zookeeper in taskmangers' > flink-config.yml. > After I fixed this, everything went well. > > On Fri, Jul 7, 2017 at 11:08 AM, Mu Kong

Re: [DISCUSS]refactor StreamConfig

Hi, Yes, that sounds very good! I like the idea of having an interface that is a view on some of the settings. We could maybe improve the naming, because to me it is not completely clear what the difference between OperatorSettings and OperatorProperties is (I mean just the name, the functional

Re: [DISCUSS] Release 1.3.2 planning

s: FLINK-7069 and FLINK-6965. > > FLINK-7069 is being merged and we have a PR for FLINK-6965. > > ~Haohui > > On Thu, Jul 6, 2017 at 1:44 AM Aljoscha Krettek wrote: > >> I’m seeing these remaining blockers: >> https://issues.apache.org/jira/browse/FLINK-7069?filte

Re: [DISCUSS] Release 1.3.2 planning

please update the Jira issues that they think should be release blocking. I would like to start building release candidates at the end of this week, if possible. And yes, I’m volunteering to be the release manager on this release. ;-) Best, Aljoscha > On 7. Jul 2017, at 16:03, Aljoscha Krett

Re: Re: [DISCUSS] FLIP-22: Eager State Declaration

provided by a user who then >> registers all the state descriptors he has. >> >> >> On 04.07.2017 20:00, Tzu-Li (Gordon) Tai wrote: >> >>> Hi Flink devs! >>> >>> I would like to propose the following FLIP - Eager State Declaration for

Re: Feel confused for the illustration of tumbling window

Hi, How do you mean? The windows in the illustration are not overlapping. I’m very happy about suggestions for improving this, though, if anyone has one. 😃 Best, Aljoscha > On 13. Jul 2017, at 11:43, jincheng sun wrote: > > Hi guys, > Feel confused for the illustration of tumbling window,

Re: Feel confused for the illustration of tumbling window

So it is not clear to which window they would belong. >> >> 2017-07-13 12:03 GMT+02:00 Aljoscha Krettek : >> >>> Hi, >>> >>> How do you mean? The windows in the illustration are not overlapping. >>> >>> I’m very happy about suggestio

Re: Request for contributor permissions

Hi, I added you to the list of contributors. Welcome to the community! :-) Best, Aljoscha > On 13. Jul 2017, at 16:16, 周思华 wrote: > > Hi devs, > I'm very interested in Flink and willing to contribute to it. Cloud anybody > give me the contributor permissions? My jira username is "sihuazhou".

[DISCUSS] Release testing procedures, Flink 1.3.2

Hi Everyone, We are on the verge of starting the release process for Flink 1.3.2 and there have been some critical issues in both Flink 1.3.0 and 1.3.1. For Flink 1.3.2 I want to make very sure that we test as much as possible. For this I’m proposing a slightly changed testing procedure [1]. Th

Re: [DISCUSS] Release testing procedures, Flink 1.3.2

production verification as well. > > Regards, > Shaoxuan > > > On Wed, Jul 19, 2017 at 9:11 PM, Aljoscha Krettek > wrote: > >> Hi Everyone, >> >> We are on the verge of starting the release process for Flink 1.3.2 and >> there have been some cr

Re: [DISCUSS] Release 1.3.2 planning

gt;> On 13 July 2017 at 4:06:06 PM, Bowen Li (bowen...@offerupnow.com) wrote: >> >> Hi Aljoscha, >> I'd like to see https://issues.apache.org/jira/browse/FLINK-6951 fixed >> in 1.3.2, if it makes sense. >> >> Thanks, >> Bowen >>

Re: [DISCUSS] Release 1.3.2 planning

2017, at 14:39, Timo Walther wrote: > > I just merged the fixes for FLINK-7137 and FLINK-7177. All blockers are > resolved from the Table & SQL API side. > > Regards, > Timo > > Am 24.07.17 um 11:14 schrieb Aljoscha Krettek: >> @Greg: I merged that. >&g

Re: [DISCUSS] Release testing procedures, Flink 1.3.2

;> wrote: >> >>> Hi, >>> >>> Regarding Kafka at-least-once bug. I could try to play with Flink 1.3.1 on >>> a real cluster to provoke this bug, by basically repeating >>> KafkaProducerTestBase#testOneToOneAtLeastOnce on a larger scale. >>

Re: [VOTE] Release Apache Flink-shaded 1.0 (RC2)

+1 - I checked the signatures and sha/md5 sums. - I verified that the published jars only contain the shaded code that they should contain > On 24. Jul 2017, at 17:43, Chesnay Schepler wrote: > > Dear Flink community, > > Please vote on releasing the following candidate as Apache Flink-shad

Re: [DISCUSS] Release 1.3.2 planning

ackwards compatibility). > > What do you think? > > - Gordon > On 25 July 2017 at 11:02:05 PM, Aljoscha Krettek (aljos...@apache.org) wrote: > > I did some preliminary cluster testing on 1.3-SNAPSHOT and it seems there is > another issue in RocksDB with incremental checkp

Re: [DISCUSS] Release 1.3.2 planning

rs, > Gordon > > On 28 July 2017 at 8:39:05 PM, Aljoscha Krettek (aljos...@apache.org) wrote: > > I think we don't have to consider that since no-one (aside from testing) ever > ran into problems with that. However, we should keep in mind merging this for > 1.4 (and 1.3

Re: [ANNOUNCE] New Flink PMC member: Chesnay Schepler

Well deserved! Congrats. :-) > On 28. Jul 2017, at 17:45, Tzu-Li (Gordon) Tai wrote: > > Congrats Chesnay! > > On Fri, Jul 28, 2017 at 11:40 PM, Matthias J. Sax wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Congrats! >> >> On 7/28/17 4:40 PM, Fabian Hueske wrote: >>>

[VOTE] Release 1.3.2, release candidate #1

Hi everyone, Please review and vote on the release candidate #1 for the version 1.3.2, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) The complete staging area is available for your review, which includes: * JIRA release notes [1]

[CANCEL] [VOTE] Release 1.3.2, release candidate #1

Unfortunately, there is a typo in the quickstarts that makes them unusable out-of-box. I'm cancelling this RC and will create a new one immediately. Sorry for the inconvenience. Best, Aljoscha > On 29. Jul 2017, at 08:06, Aljoscha Krettek wrote: > > Hi everyone, > > Pl

[VOTE] Release 1.3.2, release candidate #2

Hi everyone, Please review and vote on the release candidate #2 for the version 1.3.2, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) The complete staging area is available for your review, which includes: * JIRA release notes [1],

<    2   3   4   5   6   7   8   9   10   11   >