Re: [DISCUSS] Hold copies in HeapStateBackend

t;> So much code changes. Can you show us the key changes code for the > > object > > >> copy? > > >> Object reference maybe hold more deep reference, it can be a bomb. > > >> Can we renew a object with its data or direct use kryo for object > > &

Re: [DISCUSS] @Public libraries

I would be for also annotating library methods/classes. Maybe Robert has a stronger opinion on this because he introduced these annotations. On Tue, 22 Nov 2016 at 18:56 Greg Hogan wrote: > Hi all, > > Should stable APIs in Flink's CEP, ML, and Gelly libraries be annotated > @Public or restricte

Re: Window's Checkpoint problem

Hi, this is indeed a bug (though I would see it more as a feature since I think using the Checkpointed interface there can indeed be problematic, as Till pointed out). The problem is that the Scala Wrapper functions have to implement all kinds of interfaces so that they can forward to the wrapped f

Re: Move Row, RowInputFormat to core package

If we move it to core, we have to untangle it from Scala, as Timo said. The reason is that we would like to remove Scala from any user facing API maven packages and if we had it in core everyone would have to suffix maven packages with the Scala version. On Fri, 25 Nov 2016 at 16:47 Anton Solovev

Re: trouble using maven to deploy master branch to a private repo

Hi Steve, I think this part of create_release_files.sh (our release script) is helpful: mvn clean deploy -Prelease,docs-and-source --settings deploysettings.xml -DskipTests -Dgpg.executable=$GPG -Dgpg.keyname=$GPG_KEY -Dgpg.passphrase=$GPG_PASSPHRASE -DretryFailedDeploymentCount=10 I think -Prele

Re: [DISCUSS] Schedule and Scope for Flink 1.2

Hi, we're still working on making the backwards compatibility from 1.1 savepoints a reality. We have most of the code and some tests now but it still needs some work. This is the issue that tracks the progress on the operators that we would like to make backwards compatible: https://issues.apache.o

Re: [DISCUSS] Schedule and Scope for Flink 1.2

Yes, I'm confident that we can finish the tests until then and merge the code. On Fri, Dec 16, 2016, 17:41 Robert Metzger wrote: > Thank you for the update. Do you think you get it done until Monday > evening? > > On Fri, Dec 16, 2016 at 5:23 PM, Aljoscha Krettek > wrote:

Re: [DISCUSS] Schedule and Scope for Flink 1.2

:55 PM, Fabian Hueske > wrote: > > > >> Hi, > >> > >> I merged the Table API refactoring changes: > >> > >> - RESOLVED Clean up the packages of the Table API (FLINK-4704) > >> - RESOLVED Move Row to flink-core (FLINK-5186) >

Re: Flink gives incorrect result when event time windowing used

I'm afraid the doc is wrong here. The JavaDoc on Watermark says this about watermarks: "A Watermark tells operators that receive it that no elements with a timestamp older or equal to the watermark timestamp should arrive at the operator." The system also relies on this fact, as visible in how ti

Re: clean up jira

Thanks a lot for going through the issues and preparing this list! >From a first glance some can definitely be closed. I didn't yet find the time to look through all of them but we should definitely work and cleaning up our Jira. Cheers, Aljoscha On Wed, 21 Dec 2016 at 18:19 Anton Solovev wrote

Re: Flink gives incorrect result when event time windowing used

xOutOfOrderness; > if(potentialWM >= lastEmittedWatermark) { > lastEmittedWatermark = potentialWM; > } > return new Watermark(lastEmittedWatermark); > } > > I think those two implementation should use the same principle. > > > Aljoscha Krettek-2 wrote > > I'm afraid

Re: [ANNOUNCE] Flink 1.1.4 Released

Very nice. Good work, team! 😀 On Sat, Dec 24, 2016, 00:07 Fabian Hueske wrote: > Thank you Ufuk for your work as release manager and everybody who > contributed! > > Cheers, Fabian > > 2016-12-23 16:40 GMT+01:00 Ufuk Celebi : > > > The Flink PMC is pleased to announce the availability of Flink 1

Re: Slow duplicated tests

again. > */ > > but he incorrect, because code of both test fully equal, > one difference line very similar on bug after refactoring with inserting > recordReuse > > testSpillingHashJoinWithMassiveCollisions > 353 while ((record = buildSide.next(record)) != null) { >

Re: [DISCUSS] (Not) tagging reviewers

It seems I'm in a bit of a minority here but I like the @R tags. There are simply to many pull request for someone to keep track of all of them and if someone things that a certain person would be good for reviewing a change then tagging them helps them notice the PR. I think the tag should not me

Re: Need help on understanding flink runtime and window function

Hi,depending on which version of Flink you're using the answer changes. If you use Flink 1.1 AggregatingProcessingTimeWindowOperator should be responsible for executing that. In Flink 1.2 it should be WindowOperator. For a quick overview of how scheduling works in Flink you could look at this: htt

Re: Unregistering Managed State in Operator Backend

Just a bit of clarification, the OperatorState stuff is independent of keyed state backends, i.e. even if you use RocksDB the operator state will not be stored in RocksDB, only keyed state is stored there. Right now, when an operator state (ListState) is empty we will still write some meta data ab

Re: [VOTE] Release Apache Flink 1.2.0 (RC2)

I think this issue that Ufuk opened is also a blocker: https://issues.apache.org/jira/browse/FLINK-5670 As I comment in the Issue, at least one bigger user of Flink has run into this problem on their cluster. On Fri, 27 Jan 2017 at 10:50 Ufuk Celebi wrote: > Thanks Gyula! > > The current state

Re: clean up jira

to > >> encourage people to clean up our JIRA. > >> > >> > >> > >> On Thu, Dec 22, 2016 at 9:45 AM, Fabian Hueske > wrote: > >> > >> Hi Anton, > >>> > >>> Thanks a lot for digging through JIRA! > >>>

Re: [ANNOUNCE] Welcome Jark Wu and Kostas Kloudas as committers

Congrats! :-) On Wed, 8 Feb 2017 at 11:29 Robert Metzger wrote: > Welcome on board guys! > > If you want to try our your new privileges, you can add yourself here: > http://flink.apache.org/community.html#people (through the > apache/flink-web > repo) > > On Wed, Feb 8, 2017 at 10:52 AM, Till Ro

Re: [ANNOUNCE] Welcome Stefan Richter as a new committer

Welcome! :-) On Fri, 10 Feb 2017 at 16:10 Till Rohrmann wrote: > Great to have you on board as a committer Stefan :-) > > On Fri, Feb 10, 2017 at 3:32 PM, Greg Hogan wrote: > > > Welcome, Stefan, and thank you for your contributions! > > > > On Fri, Feb 10, 2017 at 5:00 AM, Ufuk Celebi wrote:

Re: [DISCUSS] Planning Release 1.3

+1, we can do it this time! :-) On Mon, 6 Feb 2017 at 20:19 Robert Metzger wrote: > Hi, > according to our recent time-based releases discussion, I came up with the > following deadlines for the upcoming 1.3 release: > > *Feature freeze (branch forking)*: 1 May 2017 > *Code freeze (first voting

Re: Flink Job Exception

Hi Govindarajan, the Jira issue that you linked to and which Till is currently fixing will only fix the obvious type mismatch in the Akka messages. There is also an underlying problem that causes this message to be sent in the first place. In the case of the user who originally created the Jira iss

Re: Contribute Flink

Hi, welcome to the community. :-) I'm sure Ufuk, who opened the issue, will get back to you once he notices your message. Cheers, Aljoscha On Fri, 17 Feb 2017 at 11:18 Riccardo Diomedi < riccardo.diom...@radicalbit.io> wrote: > Hi Fabian, > > I’d like to contribute mainly on Flink streaming sin

Re: Wish to Contribute - Andrea Spina

Welcome to the community, Andrea! :-) On Fri, 17 Feb 2017 at 10:22 Fabian Hueske wrote: > Hi Andrea, > > welcome to the community! > I gave you Contributor permissions. You can now assign issues to yourself. > > Best, Fabian > > 2017-02-17 9:14 GMT+01:00 Andrea Spina : > > > Dear Gordon, > > > >

Re: Reliable Distributed FS support (HCFS)

Hi, I think atomic rename is not part of the requirements. I'll add +Stephan who recently wrote this document in case he has any additional input. Cheers, Aljoscha On Thu, 16 Feb 2017 at 23:28 Vijay Srinivasaraghavan wrote: > Following up on my question regarding backed Filesystem (HCFS) > req

Re: KeyGroupRangeAssignment ?

Hi Ovidiu, what's the reason for wanting to make the parallelism equal to the number of keys? I think in general it's very hard to ensure that hashes even go to different key groups. It can always happen that all your keys (if you have so few of them) are assigned to the same parallel operator inst

Re: KeyGroupRangeAssignment ?

; If I have 100 keys and 100 slots, for each key I have the same rate of > > events, I don’t want skewed distribution. > > > > Best, > > Ovidiu > > > > > On 21 Feb 2017, at 11:38, Aljoscha Krettek > wrote: > > > > > > Hi Ovidiu, > > &

Re: [DISCUSS] Should we supply a new Iterator instance for Functions with Iterable input(s) like CoGroupFunction ?

Hi, this is probably an oversight. If it helps you implement the feature, please go ahead and add a sub-issue for solving the Iterator problem. Best, Aljoscha On Tue, 21 Feb 2017 at 16:13 Lin Li wrote: > Hi, > > When I try to implement > https://issues.apache.org/jira/browse/FLINK-5498 > vi

Re: [DISCUSS] Should we supply a new Iterator instance for Functions with Iterable input(s) like CoGroupFunction ?

I think this was mostly an oversight on my part that was possible because we didn't have good test-coverage that was enforcing correctness. Please go ahead and open an issue for re-adding the throw. On Wed, 22 Feb 2017 at 13:28 Lin Li wrote: > Thank you for the answer! > > The discussion on FLIN

Re: [DISCUSS] Project build time and possible restructuring

I'm not against splitting but I wan't to highlight that there are other options: - We could split the tests run on travis logically. For example, run unit tests and integration tests separately. This would have the benefit that you would see early on if the (fast) unit tests fail. We could also sp

[DISCUSS] Side Outputs and Split/Select

Hi Folks, Chen and I have been working for a while now on making FLIP-13 (side outputs) [1] a reality. We think we have a pretty good internal implementation and also a proposal for an API but now we need to discuss how we want to go forward with this, especially how we should deal with split/selec

Re: [DISCUSS] Code style / checkstyle

If we go for a codestyle/checkstyle I would suggest to use the Google style. This already has checkstyle, IntelliJ style, Eclipse style and a code formatting tool and is well established. However, some people will not like this style. In general, I think we will never manage to find a style that al

Re: Frontend classpath issue

Did any user have problems with the Flink 1.1 behaviour? If not, we could disable it again, by default, and add a flag for adding the user jar to all the classpaths. On Fri, 24 Feb 2017 at 14:50 Robert Metzger wrote: > I agree with you Gyula, this change is dangerous. I have seen another case >

Re: [DISCUSS] Code style / checkstyle

Just for a bit of context, this is the output of running cloc on the Flink codebase: --- Language files blankcomment code

Re: [DISCUSS] Per-key event time

This is indeed an interesting topic, thanks for starting the discussion, Jamie! I now thought about this for a while, since more and more people seem to be asking about it lately. First, I thought that per-key watermark handling would not be necessary because it can be done locally (as Paris sugge

Re: ElasticsearchSink Exception

+Tzu-Li (Gordon) Tai Do you have any idea what could be causing this? I'm asking because you recently worked on the Elasticsearch connectors, right? On Sun, 26 Feb 2017 at 04:26 Govindarajan Srinivasaraghavan < govindragh...@gmail.com> wrote: > Thanks Flavio. I tried with multiple versions but s

Re: [DISCUSS] Side Outputs and Split/Select

cting to it. (just a > quick > >> idea) > >> > >> I personally wouldn't deprecate the "universal" Split/Select API that > can > >> be used on any DataStream in favor of functionality that is only > >> accessible trhough the process fun

Re: [DISCUSS] Side Outputs and Split/Select

quire allowing ProcessFunction on a non-keyed stream, as I mentioned in my first mail (I hope). On Mon, 27 Feb 2017 at 17:45 Aljoscha Krettek wrote: > @Jamie I must have mistyped my last API proposal. This piece of code: > WindowedOperator windowedResult = input > .keyBy(..

Re: [DISCUSS] Side Outputs and Split/Select

pportedOperationException if a batch API user tries to access it. > > > > On Mon, Feb 27, 2017 at 8:56 PM, Jamie Grier > wrote: > > Aljoscha, > > > > Ahh, that is much better. As long as it's explicitly referring to late > > data I think

Re: [DISCUSS] Code style / checkstyle

>>> to merge the pull requests ;-) > > >>> > > >>> (2) Author history: This is less of an issue, I think. "git log > > >>> " and "git show -- " will still work > and > > >> one > >

Re: [DISCUSS] Per-key event time

> .map() > .window(...) // notice that we don't need keyBy because it is implicit > .reduce(...) > .map(...) > .window(...) > ... > > Would this mean that another `keyBy` isn’t allowed downstream? Or still > allowed, but we’re using the keys in `DeluxeKeye

Re: [DISCUSS] Side Outputs and Split/Select

rote: > On Tue, Feb 28, 2017 at 11:38 AM, Aljoscha Krettek > wrote: > > I see the ProcessFunction as a bit of the generalised future of FlatMap, > so > > to me it makes sense to only allow side outputs on the ProcessFunction > but > > I'm open for anything.

Re: [DISCUSS] Side Outputs and Split/Select

explicit > > tags. > > I think it is fine to start adding side output to ProcessFunction (keyed > > and non-keyed) and window operators and see how it is picked up by users. > > > > Best, Fabian > > > > > > 2017-02-28 15:42 GMT+01:00 Aljoscha Krettek : &g

[DISCUSS] FLIP-17 Side Inputs

Hi Folks, I would like to finally agree on a plan for implementing side inputs in Flink. There has already been an attempt to come to consensus [1], which resulted in two design documents. I tried to consolidate those two and also added a section about implementation plans. This is the resulting F

Re: [DISCUSS] FLIP-17 Side Inputs

y better then making it always ready from usability perspective. > > For > > > instance if I am joining against a static data set I want to wait for the > > > whole set before making it ready. This could be exposed as a user defined > > > condition that could also recognize

Re: [DISCUSS] FLIP-17 Side Inputs

at key we're off to a great > start and I think that was what you're suggesting in the design doc. > > -Jamie > > > On Thu, Mar 9, 2017 at 7:27 AM, Aljoscha Krettek > wrote: > > > Hi, > > these are all valuable suggestions and I think that we should

Re: [DISCUSS] FLIP-17 Side Inputs

after some amount of time we > conclude > that no input will ever be received for a window, and the side input > becomes ready. > > Map Side Inputs with triggers: When new data arrives for a key in Beam, > there's no way to know which value should "win", so yo

Re: [DISCUSS] Release Flink 1.1.5 / Flink 1.2.1

Thanks for kicking off the discussion! I have an open PR for - https://issues.apache.org/jira/browse/FLINK-5808: Missing verification for setParallelism and setMaxParallelism - https://issues.apache.org/jira/browse/FLINK-5713: Protect against NPE in WindowOperator window cleanup On Tue, Mar 1

Re: [DISCUSS] Release Flink 1.1.5 / Flink 1.2.1

I did in fact just open a PR for > https://issues.apache.org/jira/browse/FLINK-6001 > NPE on TumblingEventTimeWindows with ContinuousEventTimeTrigger and > allowedLateness On Tue, Mar 14, 2017, at 18:20, Vladislav Pernin wrote: > Hi, > > I would also include the following (not yet resolved) iss

Re: Question: RemoteStreamEnvironment submit in detach mode.

I would also really like to have this feature in. I'll try and see if I can find some time to get the PR into mergeable shape. On Wed, Mar 15, 2017, at 09:11, Liangfei Su wrote: > Thanks for the information, Evgeny. > > It looks no fixed version for these feature which i think it quite common > r

Re: [DISCUSS] FLIP-17 Side Inputs

input > > > readiness that is related also to windowing. By far the most useful > > > singleton side input is the result of a global reduction with an > > > associative&commutative operator. A lot of these operators also have an > > > identity element. It is nic

Re: [DISCUSS] FLIP-17 Side Inputs

separate issue, but let's > not forget about it. > > Cheers, > Gabor > > > On 2017-03-15 16:14, Aljoscha Krettek wrote: > > Hi, > > thanks for you input! :-) > > > > Regarding 1) > > I don't see the benefit of integrating windowi

Re: [DISCUSS] Code style / checkstyle

quot;git log >>>> " and "git show -- " will still work and >>> one >>>> may have to go one commit back to find out why something was changed >>>> >>>> >>>> What

Re: [DISCUSS] Code style / checkstyle

turns out. Best, Aljoscha > On 18 Mar 2017, at 08:00, Aljoscha Krettek wrote: > > I added an issue for adding a custom checkstyle.xml for flink-streaming-java > so that we can gradually add checks: > https://issues.apache.org/jira/browse/FLINK-6107. I outlined the procedure in &

Re: [DISCUSS] Project build time and possible restructuring

I prefer Jenkins to Travis by far. Working on Beam, where we have good Jenkins integration, has opened my eyes to what is possible with good CI integration. For example, look at this recent Beam PR: https://github.com/apache/beam/pull/2263 . The Jenkins

Re: [jira] [Updated] (FLINK-6126) Yet another conflict : guava

So it is resolved now? Thanks for letting us know! > On 20 Mar 2017, at 12:55, Liangfei Su wrote: > > Well...Comments added. > > This looks due to incorrect local build of flink. > > Documentation at > https://ci.apache.org/projects/flink/flink-docs-release-1.2/setup/building.html > shows >

Re: [DISCUSS] Project build time and possible restructuring

uent releases of libraries) or other criteria (e.g. core and >>> non-core) instead of build time. What would happen if the built of another >>> submodule would become too long, would we split/restructure again and >>> again? If Jenkins solves all our problems we should u

Re: Future of Queryable State Feature

I think adding this could be as simple as adding a makeWindowContentsQueryable(String) call to WindowedStream. In there, we create the StateDescriptor for keeping the window contents so we can call setQueryable() on the StateDescriptor and set the name under which it should be accessible. If yo

Re: [ANNOUNCE] New committer: Theodore Vasiloudis

Welcome (to committership)! (Since you’re already with us for such a long time…) :-) > On 21 Mar 2017, at 10:08, Tzu-Li (Gordon) Tai wrote: > > Welcome Theodore! Great to have you on board :-) > > > On March 21, 2017 at 4:35:35 PM, Robert Metzger (rmetz...@apache.org) wrote: > > Hi everybody,

Re: [VOTE] Release Apache Flink 1.1.5 (RC1)

+1 I looked at every commit since 1.1.4. The code looks good and we didn’t introduce any new dependencies, so ,legally speaking, we should be fine. > On 21 Mar 2017, at 14:40, Stephan Ewen wrote: > > +1 > > - Verified the LICENSE and NOTICE (no dependency updates, update on > RabbitMQ license

Re: [DISCUSS] FLIP-17 Side Inputs

licate >> the implementation. The triggering mechanism for the upstream window could >> define when the windowed input is ready. >> >> I would gladly contribute to a low-level requirement. If there's a >> somewhat well defined JIRA issue, I'm happy to start

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

I filed this issue, which was observed by a user: https://issues.apache.org/jira/browse/FLINK-6188 I think that’s blocking for 1.2.1. > On 24 Mar 2017, at 18:57, Ufuk Celebi wrote: > > RC1 doesn't contain Stefan's backport for the Asynchronous snapshots > for heap-based keyed state that has be

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

t; I agree with Aljoscha. > > -1 because of FLINK-6188 > > > On Sat, Mar 25, 2017 at 9:38 AM, Aljoscha Krettek wrote: >> I filed this issue, which was observed by a user: >> https://issues.apache.org/jira/browse/FLINK-6188 >> >> I think that’s blocking fo

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

amp; FLINK-6184 as well. > >>> > >>> They fix 2 metric-related issues that could arise when a Task is > >>> cancelled very early. (like, right away) > >>> > >>> FLINK-6183 fixes a memory leak where the TaskMetricGroup was never closed > &g

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

, Mar 29, 2017, at 23:08, Aljoscha Krettek wrote: > I commented on FLINK-6214: I think it's working as intended, although we > could fix the javadoc/doc. > > On Wed, Mar 29, 2017, at 17:35, Timo Walther wrote: > > A user reported that all tumbling and slinding window assigner

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

t; > > > > We should also backport the fix for FLINK-6044 to Flink 1.2.1. > > > > > > I'll take care of that. > > > > > > 2017-03-30 18:50 GMT+02:00 Aljoscha Krettek : > > > > > >> https://issues.apache.org/jira/browse/FLINK-61

Re: Side Outputs - type bounds.

Hi, You’re absolutely right. I created an Issue for this: https://issues.apache.org/jira/browse/FLINK-6246 Best, Aljoscha > On 3. Apr 2017, at 10:22, Dawid Wysakowicz wrote: > > Hi, > I am implementing emitting discarded patterns in CEP library through Side > Outputs and I have a question about

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

setting the > parallelism manually for operators that can't cope with the default -1 > parallelism. > > On Fri, Mar 31, 2017 at 9:06 PM, Aljoscha Krettek > wrote: > >> You mean reverting the changes around FLINK-5808 [1]? This is what >> introduced the follo

Re: [DISCUSS] Code style / checkstyle

() { } else { } try { } catch () { } and 2) if () { } else { } try { } catch () { } I think it’s hard to reach consensus on these so I suggest to keep allowing both styles. Any comments very welcome! :-) Best, Aljoscha > On 19. Mar 2017, at 17:09, Aljoscha Krettek wrote: > >

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

;>> 2017-04-03 16:57 GMT+02:00 Ted Yu : >>>> >>>>> Looks like #1 is better - 1.2.1 would be at least as stable as 1.2.0 >>>>> >>>>> Cheers >>>>> >>>>> On Mon, Apr 3, 2017 at 7:39 AM, Aljoscha Krettek >>>&g

Re: Flink limitations under Beam

Hi, I think you would mainly lose on performance, since Beam adds an additional layer of abstraction and has some requirements from Runners that slow things down compared to running natively on Flink. I think feature wise, the only thing that you will lose is support for Iterations/feedback edg

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

you for opening a PR for this. >> >> Chesnay, do you need more reviews for the metrics changes / backports? >> >> Are there any other release blockers for 1.2.1, or are we good to go? >> >> On Mon, Apr 3, 2017 at 6:48 PM, Aljoscha Krettek >> wrote: >&g

Re: Flink limitations under Beam

Best, Aljoscha > On 4. Apr 2017, at 09:46, amir bahmanyari wrote: > > Thanks Aljoscha, > How sever of performance difference are we talking about here? > examples of "Iterations/feedback edges" and how they get applied? > Thanks so much Aljoscha. > >

Re: [DISCUSS] Code style / checkstyle

gt; and flink-python... > > On 03.04.2017 18:33, Aljoscha Krettek wrote: >> I think enough people did already look at the checkstyle rules proposed in >> the PR. >> >> On most of the rules reaching consensus is easy so I propose to enable all >> rule

Re: Rescaling state

Hi, yes, right now this can only happen when a Job is stopped and restarted from a savepoint. In the future we might be able to do it without restarting but I think that is quite a ways in the future. Best, Aljoscha > On 18. Apr 2017, at 20:12, Vishnu Viswanath > wrote: > > Hi All, > > Regar

Re: [VOTE] Release Apache Flink 1.2.1 (RC2)

@Ted What is the hash of the commit where you saw the failing test? I think it might have been some intermediate commit because these tests are not in the code anymore on the release branch. > On 19. Apr 2017, at 18:35, Henry Saputra wrote: > > This should be the one: https://github.com/aljosc

Re: [VOTE] Release Apache Flink 1.2.1 (RC2)

There is this (somewhat pesky) issue: - https://issues.apache.org/jira/browse/FLINK-6353: Restoring using CheckpointedRestoring does not work from 1.2 to 1.2 I have the fix ready but we can do that in Flink 1.2.2. Very quickly, though. > On 20. Apr 2017, at 17:20, Henry Saputra wrote: > > LIC

Re: [VOTE] Release Apache Flink 1.2.1 (RC2)

ha: > Does this mean that users can not upgrade from 1.2.0 to 1.2.1 ? > > Can we make the minor versions easily compatible? > If so, I would prefer to cancel this release as well and do another one. > > > On Fri, Apr 21, 2017 at 12:04 PM, Aljoscha Krettek > wrote:

Re: [VOTE] Release Apache Flink 1.2.1 (RC2)

week. >>>> >>>> @Aljoscha: >>>> Does this mean that users can not upgrade from 1.2.0 to 1.2.1 ? >>>> >>>> Can we make the minor versions easily compatible? >>>> If so, I would prefer to cancel this release as well and do an

Re: Question on window ProcessFunction

Hi Tony, The reason for this is that the aggregate code is newer. The new code has less layers, compared to the reduce/fold implementation where it is InternalFunction(ReduceApplyFunction(Reduce)) instead of InteralAggregateFunction(Aggregate). Best, Aljoscha > On 26. Apr 2017, at 06:39, 魏偉哲

Re: Question on window ProcessFunction

gt; > Many thanks, > Tony Wei > > 2017-04-26 20:24 GMT+08:00 Aljoscha Krettek : > >> Hi Tony, >> The reason for this is that the aggregate code is newer. The new code has >> less layers, compared to the reduce/fold implementation where it is >> InternalFunctio

Re: [DISCUSS] Code style / checkstyle

rging it. > > On 18.04.2017 20:39, Aljoscha Krettek wrote: >> I rebased the PR [1] on current master. Is there any strong objection >> against merging this (minus the two last commits which introduce >> curly-brace-style checking). If not, I would like to merge this after tw

Re: [DISCUSS] Feature Freeze

I think there might be a typo. We haven’t yet reached issue number 6389, if I’m not mistaken. The latest as I’m writing this is 6410. > On 28. Apr 2017, at 10:00, Flavio Pompermaier wrote: > > If it's not a problem it will be great for us to include also FLINK-6398 >

Re: [DISCUSS] Feature Freeze

jira/browse/FLINK-6398 > > On Fri, Apr 28, 2017 at 11:48 AM, Aljoscha Krettek > wrote: > >> I think there might be a typo. We haven’t yet reached issue number 6389, >> if I’m not mistaken. The latest as I’m writing this is 6410. >> >>> On 28. Apr 2017, at 10:

Re: Question on checkpointing

Hi Blake, I didn’t see any mails on the user mailing list regarding this. Is it still relevant. From the looks of it you might be interested in the savepoints feature: https://ci.apache.org/projects/flink/flink-docs-release-1.3/setup/savepoints.html

Re: [DISCUSS] Feature Freeze

TypeSerializers: https:// >>>>> github.com/apache/flink/pull/3804 >>>>> PR #2 (will open soon) integrate serializer reconfiguration into state >>>>> restore flow (FLINK-6425) >>>>> >>>>> 2. Major new functionality

Re: Examples of Flink windowing unit tests, and option to bring in flink-spector to Flink

Hi, Yes, unfortunately there are no good unit test examples for testing Flink jobs (with windowing or without). And yes, I would like to have something like flink-spector (or flink-spector) as part of Flink as the promoted way of doing Job testing. In my opinion this is blocked on a good way of

Re: Examples of Flink windowing unit tests, and option to bring in flink-spector to Flink

able law or agreed to in writing, software > * distributed under the License is distributed on an "AS IS" BASIS, > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > * See the License for the specific language governing permissions and > * limitations

Re: [DISCUSS] What is a "Blocker" in our JIRA?

IMHO, the problem with the “add documentation” issues is that they should ideally have been documented as part of the feature development. (Full disclosure: I’m not innocent there and the Per-Key Window State Doc is somewhat my fault.) Sometimes, though, several features are developed over the c

Re: ListState to List

Hi, The interface is restrictive on purpose because depending on the state backend it might not be possible to provide a List-like interface. There might be state backends that stream in the list from somewhere else or other restrictions. If we now allowed a more general interface here we would

Re: [DISCUSS] Backwards compatibility policy.

Normally, I’m the first one to suggest removing everything that is not absolutely necessary in order to have a clean code base. On this issue, though, I think we should support restoring from old Savepoints as far back as possible if it does not make the code completely unmaintainable. Some user

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

+1 I did: - manually check the release using the new end-to-end tests: https://github.com/apache/flink/pull/3911 . - verify that the source builds - Check the (transitive) dependencies of flink-dist compared to 1.2.x. The new deps are: com.squareup.

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

Yes, FLINK-6783 might even have been a release blocker…. It’s a new feature that simply doesn’t work in most cases. > On 31. May 2017, at 14:51, Timo Walther wrote: > > We should also include FLINK-6783. It seems that WindowedStream::aggregate is > broken right now. > > > Am 31.05.17 um 14:3

Re: Building only flink-java8 module

Hi, I think you can use something like mvn verify -am -pl flink-java8 (From the base directory) The -pl flag will tell maven to only do that module while -am tells it to also builds its dependencies. This might or might not also run the tests on the dependent-upon projects, I’m not sure. As

Re: Building only flink-java8 module

the command given by Aljoscha, I got: >> >> https://pastebin.com/8WTGvdFQ >> >> FYI >> >> On Thu, Jun 1, 2017 at 8:17 AM, Aljoscha Krettek >> wrote: >> >>> Hi, >>> >>> I think you can use something like >>> >

Re: Building only flink-java8 module

. >>>> Just an example: >>>> >>>> >>>> >>>> 16:12:53,103 INFO >>>> org.apache.flink.runtime.taskmanager.TaskManagerRegistrationTest -

Re: [DISCUSS] Release Apache Flink 1.3.1

I would also like to raise another potential blocker: it’s currently not easily possible for users to start a job in local mode in the IDE and to then interact with that cluster, say for experimenting with queryable state. At least one user walked into this problem already with the 1.3.0 RC: ht

Re: FlinkML on slack

Hi, Is the slack invite based? If yes, could you please send me one? Best, Aljoscha > On 7. Jun 2017, at 21:56, Stavros Kontopoulos > wrote: > > Hi all, > > We took the initiative to create the organization for FlinkML on slack > (thnx Eron). > There is now a channel for model-serving >

Re: [DISCUSS] Release Apache Flink 1.3.1

ill > > On Wed, Jun 7, 2017 at 4:59 PM, Aljoscha Krettek > wrote: > >> I would also like to raise another potential blocker: it’s currently not >> easily possible for users to start a job in local mode in the IDE and to >> then interact with that cluster, say for expe

Re: FlinkML on slack

Thanks! > On 8. Jun 2017, at 11:21, Stavros Kontopoulos > wrote: > > Hi Aljoscha, > > Slack is invite only to the best of my knowledge, I just sent you an > invitation. > > Best, > Stavros > > > On Thu, Jun 8, 2017 at 11:31 AM, Aljoscha Krettek

<    7   8   9   10   11   12   13   14   15   16   >