Hi Everybody!
Thanks a lot for the warn welcome!
I am really happy about joining Flink committer team and hope to help the
project to grow more.
Cheers,
Andrey
On Fri, Aug 16, 2019 at 11:10 AM Terry Wang wrote:
> Congratulations Andrey!
>
> Best,
> Terry Wang
>
>
>
> 在 2019年8月15日，下午9:27，Hequn
Thanks for the votes!
We have 4 +1's from Timo, Jark, Dawid and Aljoscha.
Thank you for the vote.
Since there are no disapproving votes and the voting time has passed, I
will see this FLIP as approved to be adopted into Apache Flink.
Best,
Jingsong Lee
--
Hi,
https://issues.apache.org/jira/browse/FLINK-13752 turns out to be an actual
blocker, so we would have to close this RC now in favor of a new one.
Since we are already quite past the planned release time for 1.9.0, I would
like to limit the new changes included in RC3 to only the following:
-
Hi Gordon,
I remember we mentioned earlier that if there is an additional RC, we can
piggyback the GCP PubSub API change (
https://issues.apache.org/jira/browse/FLINK-13231). It is a small patch to
avoid future API change. So should be able to merge it very shortly. Would
it be possible to include
I'm late to the party... Welcome and congrats! :-)
– Ufuk
On Mon, Aug 19, 2019 at 9:26 AM Andrey Zagrebin
wrote:
> Hi Everybody!
>
> Thanks a lot for the warn welcome!
> I am really happy about joining Flink committer team and hope to help the
> project to grow more.
>
> Cheers,
> Andrey
>
> O
+1 for only cherry picking FLINK-13752 and the LICENSE fixes into RC 3.
Cheers,
Till
On Mon, Aug 19, 2019 at 9:48 AM Becket Qin wrote:
> Hi Gordon,
>
> I remember we mentioned earlier that if there is an additional RC, we can
> piggyback the GCP PubSub API change (
> https://issues.apache.org/j
+1 for Gordon's approach.
If we do that, we can probably skip re-testing everything and mainly need
to verify the release artifacts (signatures, build from source, etc.).
If we open the RC up for changes, I fear a lot of small issues will rush in
and destabilize the candidate again, meaning we ha
Hi Rishindra,
I've pulled in Gordon who has worked on the Elasticsearch connector. He
might be able to review the PR.
Cheers,
Till
On Mon, Aug 19, 2019 at 8:10 AM Rishindra Kumar
wrote:
> Hi,
>
> I created pull request with the change I proposed in the comment. Could
> someone please review it
Hi Thomas,
I've given you access. You should be able to access it now with your Apache
account. Please let me know if something is not working.
Cheers,
Till
On Mon, Aug 19, 2019 at 6:15 AM Thomas Weise wrote:
> Hi,
>
> I would like to be able to edit pages in the Confluence Flink space. Can
>
I did a quick test: a normal "mvn clean install -DskipTests -Drat.skip=true
-Dmaven.javadoc.skip=true -Punsafe-mapr-repo” on my machine takes about 14
minutes. After removing all mentions of maven-shade-plugin the build time goes
down to roughly 11.5 minutes. (Obviously the resulting Flink won’t
Hi Rishindra,
Thanks for the pull request. I've left a comment on it.
Cheers,
Gordon
On Mon, Aug 19, 2019 at 10:16 AM Till Rohrmann wrote:
> Hi Rishindra,
>
> I've pulled in Gordon who has worked on the Elasticsearch connector. He
> might be able to review the PR.
>
> Cheers,
> Till
>
> On Mon
Thank you Gordon. I will have a look.
--
*Maddila Rishindra Kumar*
*Software Engineer*
*Walmartlabs India*
*Contact No: +919967379528 | Alternate E-mail
ID: rishindra.madd...@walmartlabs.com *
Hi Everybody,
Thanks for your feedback guys and sorry for not getting back to the
discussion for some time.
@SHI Xiaogang
About breaking lines for thrown exceptions:
Indeed that would prevent growing the throw clause indefinitely.
I am a bit concerned about putting the right parenthesis and/or th
Hey, Robert.
Updating the roadmap is something I can work on (and also have on my radar,
moving forward). Already had a quick word with Stephan and he's available
to provide support, if needed.
Marta
On Sun, Aug 18, 2019 at 4:46 PM Stephan Ewen wrote:
> I could help with that.
>
> On Fri, Aug
Hi Xintong,
Thanks for your detailed proposal. I think many users are suffering from
waste of resources. The resource spec of all task managers are same and we
have to increase all task managers to make the heavy one more stable. So we
will benefit from the fine grained resource management a lot.
Hi All,
It looks like this proposal has an approval and we can conclude this
discussion.
Additionally, I agree with Piotr we should really force the proven good
reasoning for setting the capacity to avoid confusion, redundancy and other
already mentioned things while reading and maintaining the co
I quickly went through all the changelogs for Netty 4.1.32 (which we
currently use) to the latest Netty 4.1.39.Final. Below, you will find a
list of bug fixes and performance improvements that may affect us. Nice
changes we could benefit from, also for the Java > 8 efforts. The most
important ones
Nice, thanks! Looking forward to the PR
On Mon, Aug 19, 2019 at 11:08 AM Marta Paes Moreira
wrote:
> Hey, Robert.
>
> Updating the roadmap is something I can work on (and also have on my radar,
> moving forward). Already had a quick word with Stephan and he's available
> to provide support, if n
Hi Stephan,
thanks for your suggestions. Let me give you some background about the
decisions made in this FLIP:
1. Goal: The FLIP is labelled "evolve" not "rework" because we did not
want to change the entire configuration infrastructure. Both for
backwards-compatibility reasons and the amou
Hi Gordon,
I agree that we should pick the minimal set of changes to shorten the
release testing time.
However, I would like to include FLINK-13699 into RC3. FLINK-13699 is a
critical DDL issue, and is a small change to flink table (won't affect the
runtime feature and stability).
I will do some t
I support Jark's fix for FLINK-13699 because it would be disappointing
if both DDL and connectors are ready to handle DATE/TIME/TIMESTAMP but a
little component in the middle of the stack is preventing an otherwise
usable feature. The changes are minor.
Thanks,
Timo
Am 19.08.19 um 13:24 schr
I've merged the fix for FLINK-13752. Hence we are good to go to create the
new RC.
Cheers,
Till
On Mon, Aug 19, 2019 at 1:30 PM Timo Walther wrote:
> I support Jark's fix for FLINK-13699 because it would be disappointing
> if both DDL and connectors are ready to handle DATE/TIME/TIMESTAMP but a
+1
On Sun, Aug 18, 2019 at 4:30 PM Stephan Ewen wrote:
> +1
>
> On Sun, Aug 18, 2019 at 3:31 PM Till Rohrmann
> wrote:
>
> > +1
> >
> > On Fri, Aug 16, 2019 at 4:54 PM Yu Li wrote:
> >
> > > Hi All,
> > >
> > > Since we have reached a consensus in the discussion thread [1], I'd
> like
> > to
>
About the "-XX:MaxDirectMemorySize" discussion, maybe let me summarize it a
bit differently:
We have the following two options:
(1) We let MemorySegments be de-allocated by the GC. That makes it segfault
safe. But then we need a way to trigger GC in case de-allocation and
re-allocation of a bunch
Thinks for the comments, Yang.
Regarding your questions:
1. How to calculate the resource specification of TaskManagers? Do they
>have them same resource spec calculated based on the configuration? I
> think
>we still have wasted resources in this situation. Or we could start
>Task
Looking at FLINK-13699, it seems to be very local to Table API and HBase
connector.
We can cherry-pick that without re-running distributed tests.
On Mon, Aug 19, 2019 at 1:46 PM Till Rohrmann wrote:
> I've merged the fix for FLINK-13752. Hence we are good to go to create the
> new RC.
>
> Cheer
Thanks for the comments, Stephan. Summarized in this way really makes
things easier to understand.
I'm in favor of option 2, at least for the moment. I think it is not that
difficult to keep it segfault safe for memory manager, as long as we always
de-allocate the memory segment when it is release
My main concern with option 2 (manually release memory) is that segfaults
in the JVM send off all sorts of alarms on user ends. So we need to
guarantee that this never happens.
The trickyness is in tasks that uses data structures / algorithms with
additional threads, like hash table spill/read and
Hi stephan:
About option 2:
if additional threads not cleanly shut down before we can exit the task:
In the current case of memory reuse, it has freed up the memory it
uses. If this memory is used by other tasks and asynchronous threads
of exited task may still be writing, there will be concurr
Hi everyone,
We would like to start a discussion thread on "FLIP-56: Dynamic Slot
Allocation" [1]. This is originally part of the discussion thread for
"FLIP-53: Fine Grained Resource Management" [2]. As Till suggested, we
would like split the original discussion into two topics, and start a
separ
Hi everyone,
As Till suggested, the original "FLIP-53: Fine Grained Resource Management"
splits into two separate FLIPs,
- FLIP-53: Fine Grained Operator Resource Management [1]
- FLIP-56: Dynamic Slot Allocation [2]
We'll continue using this discussion thread for FLIP-53. For FLIP-56, I
j
Quick question for option 1.1 Stephan: Does this variant entail that we
distinguish between native and direct memory off heap managed memory? If
this is the case, then it won't be possible for users to run a streaming
job using RocksDB and a batch DataSet job on the same session cluster
unless they
Thanks for the inputs, Jingsong.
Let me try to summarize your points. Please correct me if I'm wrong.
- Memory consumers should always avoid returning memory segments to
memory manager while there are still un-cleaned structures / threads that
may use the memory. Otherwise, it would caus
Jingsong Lee created FLINK-13780:
Summary: Introduce ExpressionConverter to legacy planner
Key: FLINK-13780
URL: https://issues.apache.org/jira/browse/FLINK-13780
Project: Flink
Issue Type: S
Jingsong Lee created FLINK-13781:
Summary: Use new Expression in RexNodeToExpressionConverter
Key: FLINK-13781
URL: https://issues.apache.org/jira/browse/FLINK-13781
Project: Flink
Issue Type
Jingsong Lee created FLINK-13782:
Summary: Implement type inference for logic functions
Key: FLINK-13782
URL: https://issues.apache.org/jira/browse/FLINK-13782
Project: Flink
Issue Type: Sub-
Jingsong Lee created FLINK-13783:
Summary: Implement type inference for string functions
Key: FLINK-13783
URL: https://issues.apache.org/jira/browse/FLINK-13783
Project: Flink
Issue Type: Sub
Jingsong Lee created FLINK-13786:
Summary: Implement type inference for other functions
Key: FLINK-13786
URL: https://issues.apache.org/jira/browse/FLINK-13786
Project: Flink
Issue Type: Sub-
Jingsong Lee created FLINK-13785:
Summary: Implement type inference for time functions
Key: FLINK-13785
URL: https://issues.apache.org/jira/browse/FLINK-13785
Project: Flink
Issue Type: Sub-t
Jingsong Lee created FLINK-13784:
Summary: Implement type inference for math functions
Key: FLINK-13784
URL: https://issues.apache.org/jira/browse/FLINK-13784
Project: Flink
Issue Type: Sub-t
Hi all,
I have summarized all arguments mentioned so far + some additional research
into a Wiki page here:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=125309279
I'm happy to hear further comments on my summary! I'm pretty sure we can
find more pro's and con's for the differen
Kaibo Zhou created FLINK-13787:
--
Summary: PrometheusPushGatewayReporter does not cleanup TM metrics
when run on kubernetes
Key: FLINK-13787
URL: https://issues.apache.org/jira/browse/FLINK-13787
Project:
Hi all,
Sorry for not getting back to this discussion for some time.
It looks like in general we agree on the initially suggested points:
- Always use Optional only to return nullable values in the API/public
methods
- Only if you can prove that Optional usage would lead to a
pe
For the use of optional in private methods: It sounds fine to me, because
it means it is strictly class-internal (between methods and helper methods)
and does not leak beyond that.
On Mon, Aug 19, 2019 at 5:53 PM Andrey Zagrebin
wrote:
> Hi all,
>
> Sorry for not getting back to this discussion
@Andrey Will you open a PR to add this to the code style?
On Mon, Aug 19, 2019 at 11:51 AM Andrey Zagrebin
wrote:
> Hi All,
>
> It looks like this proposal has an approval and we can conclude this
> discussion.
> Additionally, I agree with Piotr we should really force the proven good
> reasoning
Seth Wiesman created FLINK-13788:
Summary: Document state migration constraints on keys
Key: FLINK-13788
URL: https://issues.apache.org/jira/browse/FLINK-13788
Project: Flink
Issue Type: Impr
I personally prefer not to break lines with few parameters.
It just feels unnecessarily clumsy to parse the breaks if there are only
two or three arguments with short names.
So +1
- for a hard line length limit
- allowing arguments on the same line if below that limit
- with consistent argum
Thanks for the comments and fast fixes.
@Becket Qin I've quickly looked at the changes to
the PubSub connector. Given that it is a API-breaking change and is quite
local as a configuration change, I've decided to include that change in RC3.
@Jark @Timo Walther I'll be adding FLINK-13699 as well.
@Xintong: Concerning "wait for memory users before task dispose and memory
release": I agree, that's how it should be. Let's try it out.
@Xintong @Jingsong: Concerning " JVM does not wait for GC when allocating
direct memory buffer": There seems to be pretty elaborate logic to free
buffers when al
Hi all,
A while back we discussed upgrading flink-connector-kinesis module to
Apache 2.0 license so that its jar can be published as part of official
Flink releases. Given we have a large user base using Flink with
kinesis/dynamodb streams, it'll free users from building and maintaining
the module
Hello,
Not sure if anyone encountered this issue before. I tried to run “mvn clean
install” on flink release-1.8, but some unit tests in flink-arvo module failed:
[ERROR] Tests run: 12, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 4.81 s
<<< FAILURE! - in org.apache.flink.formats.avro.ty
Hao Dang created FLINK-13789:
Summary: Transactional Id Generation fails due to user code
impacting formatting string
Key: FLINK-13789
URL: https://issues.apache.org/jira/browse/FLINK-13789
Project: Flink
It’s probably the encoding problem. The environment I ran the unit tests on
uses ANSI_X3.4-1968
It looks like we have to use "en_US.UTF-8"
> On Aug 19, 2019, at 1:44 PM, Ethan Li wrote:
>
> Hello,
>
> Not sure if anyone encountered this issue before. I tried to run “mvn clean
> install” o
One of the perks of being committers is be able to commit code without
asking from another committer. Having said that, I think we rely on
maturity of the committers to know when to ask for reviews and when to
commit directly.
For example, if someone just change typos on comments or simple rename
Bowen Li created FLINK-13790:
Summary: Support -e option with a sql script file as input
Key: FLINK-13790
URL: https://issues.apache.org/jira/browse/FLINK-13790
Project: Flink
Issue Type: Sub-tas
Thanks!
On Mon, Aug 19, 2019 at 1:19 AM Till Rohrmann wrote:
> Hi Thomas,
>
> I've given you access. You should be able to access it now with your Apache
> account. Please let me know if something is not working.
>
> Cheers,
> Till
>
> On Mon, Aug 19, 2019 at 6:15 AM Thomas Weise wrote:
>
> >
Nico Kruber created FLINK-13791:
---
Summary: Speed up sidenav by using group_by
Key: FLINK-13791
URL: https://issues.apache.org/jira/browse/FLINK-13791
Project: Flink
Issue Type: Sub-task
Hi all,
Release candidate #3 for Apache Flink 1.9.0 is now ready for your review.
Please review and vote on release candidate #3 for version 1.9.0, as
follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
The complete staging area is available
Vote thread for RC3 has been started:
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Apache-Flink-1-9-0-release-candidate-3-td31988.html
On Mon, Aug 19, 2019 at 6:32 PM Tzu-Li (Gordon) Tai
wrote:
> Thanks for the comments and fast fixes.
>
> @Becket Qin I've quickly looked
+1 (non-binding)
- checked release notes: OK
- checked sums and signatures: OK
- repository appears to contain all expected artifacts
- source release
- contains no binaries: OK
- contains no 1.9-SNAPSHOT references: OK
- build from source: OK (8u102)
- binary release
- no exam
We suddenly skipped FLIP-55 lol.
Xintong Song 于2019年8月19日周一 下午10:23写道：
> Hi everyone,
>
> We would like to start a discussion thread on "FLIP-56: Dynamic Slot
> Allocation" [1]. This is originally part of the discussion thread for
> "FLIP-53: Fine Grained Resource Management" [2]. As Till sugge
+1 (non-binding)
- build from source: OK(8u212)
- check local setup tutorial works as expected
Best,
tison.
Yu Li 于2019年8月20日周二 上午8:24写道：
> +1 (non-binding)
>
> - checked release notes: OK
> - checked sums and signatures: OK
> - repository appears to contain all expected artifacts
> - source
Hi Aljoscha,
Thanks for your reply and participance. The Google Doc you linked to
requires
permission and I think you could use a share link instead.
I agree with that we almost reach a consensus that JobClient is necessary to
interacte with a running Job.
Let me check your open questions one by
63 matches
Mail list logo
