Congratulations, Hangxiang!
Regards,
Roman
On Wed, Aug 9, 2023 at 12:49 PM Benchao Li wrote:
> Congrats, Hangxiang!
>
> Jing Ge 于2023年8月8日周二 17:44写道：
>
> > Congrats, Hangxiang!
> >
> > Best regards,
> > Jing
> >
> > On Tue, Aug 8, 2023 at 3:04 PM Yangze Guo wrote:
> >
> > > Congrats, Hangxia
Congratulations, Yanfey!
Regards,
Roman
On Wed, Aug 9, 2023 at 12:49 PM Benchao Li wrote:
> Congrats, YanFei!
>
> Jing Ge 于2023年8月8日周二 17:41写道：
>
> > Congrats, YanFei!
> >
> > Best regards,
> > Jing
> >
> > On Tue, Aug 8, 2023 at 3:04 PM Yangze Guo wrote:
> >
> > > Congrats, Yanfei!
> > >
>
Thanks for the proposal,
Starting with the minimal functionality and expanding if necessary as the
FLIP describes makes a lot of sense to me.
Regards,
Roman
On Wed, Nov 15, 2023, 9:31 PM Jing Ge wrote:
> Hi Piotr,
>
> Sorry for the late reply and thanks for the proposal, it looks awesome!
>
>
Thanks Piotr, the proposal totally makes sense to me.
Does it depend on FLIP-384 for voting?
Otherwise, we could probably start the vote already as there're no counter
proposals or objections.
Regards,
Roman
On Tue, Nov 7, 2023, 1:19 PM Piotr Nowojski
wrote:
> Hey, sorry for the misclick. Fixe
Thanks for the proposal,
Can you please explain:
1. why the existing MetricGroup interface can't be used? It already had
methods to add metrics and spans ...
2. IIUC, based on these numbers, we're going to report span(s). Shouldn't
the backend report them as spans?
3. How is the implementation s
tart with the simplest min/max/sum/avg, and let's see in
> which direction (if any) we need to evolve
> that. Alternative to percentiles is previously mentioned to report
> separately each subtask's initialisation/checkpointing span.
>
> Best,
> Piotrek
>
> [1]
&
+1 (binding)
Thanks for the proposal
Regards,
Roman
On Wed, Nov 22, 2023, 10:08 AM Piotr Nowojski
wrote:
> Thanks Rui!
>
> +1 (binding)
>
> Best,
> Piotrek
>
> śr., 22 lis 2023 o 08:05 Hangxiang Yu napisał(a):
>
> > +1 (binding)
> > Thanks for your efforts!
> >
> > On Mon, Nov 20, 2023 at 11
+1 (binding)
Regards,
Roman
On Wed, Nov 22, 2023, 7:08 AM Zakelly Lan wrote:
> +1(non-binding)
>
> Best,
> Zakelly
>
> On Wed, Nov 22, 2023 at 3:04 PM Hangxiang Yu wrote:
>
> > +1 (binding)
> > Thanks for driving this again!
> >
> > On Wed, Nov 22, 2023 at 10:30 AM Rui Fan <1996fan...@gmail.co
+1 (binding)
Regards,
Roman
On Wed, Nov 22, 2023, 7:30 AM Hangxiang Yu wrote:
> +1(binding)
>
> On Wed, Nov 22, 2023 at 10:29 AM Rui Fan <1996fan...@gmail.com> wrote:
>
> > +1(binding)
> >
> > Best,
> > Rui
> >
> > On Wed, Nov 22, 2023 at 1:20 AM Piotr Nowojski
> > wrote:
> >
> > > Hi All,
> >
+1 (binding)
Regards,
Roman
On Wed, Nov 22, 2023 at 12:55 PM Rui Fan <1996fan...@gmail.com> wrote:
> +1(binding)
>
> Thanks for driving this proposal!
>
> Best,
> Rui
>
> On Wed, Nov 22, 2023 at 7:44 PM Piotr Nowojski
> wrote:
>
> > Hi All,
> >
> > I'd like to start a vote on the FLIP-386: Su
+1 (non-binding)
Regarding Yu's suggestion about *Roadmap* or *Future Work* section, I think
it's a good idea.
Currently, some MVP limitations are mentioned at the end of the document,
so we can extract and expand it.
As for the recovery speed it's not a priority currently, but we could also
menti
Hi everyone,
I'm currently working on exactly-once JDBC sink implementation for Flink.
Any ideas and/or feedback are welcome.
I've considered the following options:
1. Two-phase commit. This is similar to Kafka sink.
XA or database-specific API can be used. In case of XA, each sink subtask
acts a
Hi everyone,
I'd like to kick off the discussion on the redesign of
TwoPhaseCommitSinkFunction [1].
The primary motivation is to provide a solution that suits the needs of
both Kafka Sink and JDBC exactly once sink. Other possible scenarios
include File Sink, WAL and batch jobs.
Current abstract
Hi everyone,
Thanks for the proposal and the discussion.
I couldn't find much details on how exactly the values of
ExclusiveBuffersPerChannel and FloatingBuffersPerGate are calculated.
I guess that
- the threshold evaluation is done on JM
- floating buffers calculation is done on TM based on the
the suggestion. I have a test about different exchange types,
> forward
> and rescale, and the results show no differences from the all-to-all type,
> which
> is also understandable, because the network memory usage is calculated
> with numChannels, independent of the edge type.
>
>
Congratulations Anton, well deserved!
Regards,
Roman
On Tue, Feb 21, 2023 at 9:34 AM Martijn Visser
wrote:
> Congratulations Anton!
>
> On Tue, Feb 21, 2023 at 8:08 AM Lincoln Lee
> wrote:
>
> > Congratulations, Anton!
> >
> > Best,
> > Lincoln Lee
> >
> >
> > Guowei Ma 于2023年2月21日周二 15:05写道
Congratulations Rui!
Regards,
Roman
On Mon, Feb 20, 2023 at 5:58 PM Anton Kalashnikov
wrote:
> Congrats Rui!
>
> --
> Best regards,
> Anton Kalashnikov
>
> On 20.02.23 17:53, Matthias Pohl wrote:
> > Congratulations, Rui :)
> >
> > On Mon, Feb 20, 2023 at 5:10 PM Jing Ge
> wrote:
> >
> >> Con
Hi,
Thanks for the update, I think distinguishing the rescaling behaviour and
the desired parallelism declaration is important.
Having the ability to specify min parallelism might be useful in
environments with multiple jobs: Scheduler will then have an option to stop
the less suitable job.
In ot
+1 (binding)
Thanks David, and everyone involved :)
Regards,
Roman
On Wed, Mar 1, 2023 at 8:01 AM Gyula Fóra wrote:
> +1 (binding)
>
> Looking forward to this :)
>
> Gyula
>
> On Wed, 1 Mar 2023 at 04:02, feng xiangyu wrote:
>
> > +1 (non-binding)
> >
> > ConradJam 于2023年3月1日周三 10:37写道：
>
+1 (binding)
The FLIP LGTM, thanks Panos!
Regards,
Roman
On Thu, Apr 20, 2023 at 1:33 PM Hong Teoh wrote:
> +1 (non-binding)
>
> Thank you for driving this effort, Panagiotis.
>
> Regards,
> Hong
>
>
> > On 20 Apr 2023, at 12:16, David Morávek wrote:
> >
> > Thanks for the update!
> >
> > +1
+1 (binding)
Regards,
Roman
On Fri, Mar 29, 2024 at 7:01 AM Xintong Song wrote:
> +1 (binding)
>
> Best,
>
> Xintong
>
>
>
> On Fri, Mar 29, 2024 at 12:51 PM Yuepeng Pan
> wrote:
>
> > +1(non-binding)
> >
> > Best,
> > Yuepeng Pan
> >
> >
> > On 2024/03/29 03:03:53 Yunfeng Zhou wrote:
> > > +
+1 (binding)
Regards,
Roman
On Fri, Mar 29, 2024 at 8:08 AM yue ma wrote:
> +1 (non-binding)
>
> Yanfei Lei 于2024年3月27日周三 18:28写道：
>
> > Hi everyone,
> >
> > Thanks for all the feedback about the FLIP-425: Asynchronous Execution
> > Model [1]. The discussion thread is here [2].
> >
> > The vo
Hi,
Thanks for writing the proposal and preparing the upgrade.
FRocksDB definitely needs to be kept in sync with the upstream and the new
APIs are necessary for faster rescaling.
We're already using a similar version internally.
I reviewed the FLIP and it looks good to me (disclaimer: I took pa
Congrats, well deserved!
Regards,
Roman
On Thu, Apr 18, 2024 at 9:06 AM xiangyu feng wrote:
> Congratulations, Zakelly!
>
>
> Regards,
> Xiangyu Feng
>
> yh z 于2024年4月18日周四 14:27写道：
>
> > Congratulations Zakelly!
> >
> > Best regards,
> > Yunhong (swuferhong)
> >
> > gongzhongqiang 于2024年4月1
Thanks for the proposal, I definitely see the need for this improvement, +1.
Regards,
Roman
On Tue, Apr 30, 2024 at 3:11 PM Piotr Nowojski wrote:
> Hi Yanfei,
>
> Thanks for the feedback!
>
> > 1. Currently when AbstractStreamOperator or AbstractStreamOperatorV2
> > processes a watermark, the
Hi Piotr,
+1 for the proposal, the recovery time improvements are significant IMO
Thanks for pushing this
Regards,
Roman
On Tue, Apr 30, 2024 at 3:15 PM Piotr Nowojski wrote:
> Hi all!
>
> I would like to put under discussion:
>
> FLIP-444: Native file copy support
> https://cwiki.apache.org
+1 (binding)
Regards,
Roman
On Mon, May 6, 2024 at 11:56 AM gongzhongqiang
wrote:
> +1 (non-binding)
>
> Best,
> Zhongqiang Gong
>
> yue ma 于2024年5月6日周一 10:54写道：
>
> > Hi everyone,
> >
> > Thanks for all the feedback, I'd like to start a vote on the FLIP-447:
> > Upgrade FRocksDB from 6.20.3
Hi everyone,
FLINK-26985 was just merged.
Sorry for the long delay.
Regards,
Roman
On Tue, Apr 5, 2022 at 11:52 AM Yuan Mei wrote:
>
> FLINK-26985 was discovered just before last weekend.
>
> We will get it resolved first thing after the holiday (tomorrow).
>
> Best
> Yuan
>
> On Tue, Apr 5, 2
Hi,
Thanks for the proposal Dawid, I have some questions and remarks:
1. How will stop-with-savepoint be handled?
Shouldn't side effects be enforced in this case? (i.e. send
notifyCheckpointComplete)
2. Instead of forcing re-upload, can we "inverse control" in no-claim mode?
Anyways, any externa
ink delaying the completion of an independent savepoint to a
> closer undefined future is not a nice property of savepoints.
>
> Re 4. Good point. We should make sure the first completed checkpoint has the
> independent/full checkpoint property rather than just the first triggered.
>
tuation we have right now that you never know when it is safe to
> delete a retained checkpoint.
>
> BTW, the intention for the "claim" mode was to support cases when users
> are concerned with the performance of the first checkpoint. In those
> cases they can claim the check
older - depending on those attributes in state handle
> 2. (SST files from newer checkpoints are re-uploaded depending on
> confirmation currently; so yes there is tracking, but it's different)
> 3. SharedStateRegistry must allow replacing state under the existing
> key; o
The situation is probably a bit different now compared to the previous
upgrade: some users might be using Amazon Coretto (or other builds)
which have longer support.
Still +1 for deprecation to trigger migration, and thanks for bringing this up!
Regards,
Roman
On Thu, Nov 25, 2021 at 10:09 AM Ar
to understand by users. They can reliably tell when they
> > can expect the checkpoint to be deletable. If we see that the time to take
> > the 1st checkpoint becomes a problem we can extend the set of restore
> > methods and e.g. add a "claim-temporarily" method.
> &
+1
Thanks for driving this effort Dawid
Regards,
Roman
On Wed, Dec 1, 2021 at 2:04 PM Konstantin Knauf wrote:
>
> Thanks, Dawid.
>
> +1
>
> On Wed, Dec 1, 2021 at 1:23 PM Dawid Wysakowicz
> wrote:
>
> > Dear devs,
> >
> > I'd like to open a vote on FLIP-193: Snapshots ownership [1] which was
Thanks for clarifying (I was initially confused by merging state files
rather than output files).
> At some point, Flink will definitely have some WAL adapter that can turn any
> sink into an exactly-once sink (with some caveats). For now, we keep that as
> an orthogonal solution as it has a rat
Congratulations, Matthias!
Regards,
Roman
On Mon, Dec 6, 2021 at 11:04 AM Yang Wang wrote:
>
> Congratulations, Matthias!
>
> Best,
> Yang
>
> Sergey Nuyanzin 于2021年12月6日周一 下午3:35写道：
>
> > Congratulations, Matthias!
> >
> > On Mon, Dec 6, 2021 at 7:33 AM Leonard Xu wrote:
> >
> > > Congratula
Congratulations, Ingo!
Regards,
Roman
On Mon, Dec 6, 2021 at 11:05 AM Yang Wang wrote:
>
> Congratulations, Ingo!
>
> Best,
> Yang
>
> Sergey Nuyanzin 于2021年12月6日周一 下午3:35写道：
>
> > Congratulations, Ingo!
> >
> > On Mon, Dec 6, 2021 at 7:32 AM Leonard Xu wrote:
> >
> > > Congratulations, Ingo!
Hi,
I think Chesnay's suggestion to double-check the bundle makes sense.
Additionally, I'd try flink-connector-jdbc_2.12 instead of
flink-connector-jdbc_2.11.
Regards,
Roman
On Wed, Jan 12, 2022 at 12:23 PM Chesnay Schepler wrote:
>
> I would try double-checking whether the jdbc connector was t
Hi Ronak,
You shared a screenshot of JM. Do you mean that exception also happens
on JM? (I'd rather assume TM).
Could you explain the join clause: left join ccmversionsumapTable cvsm
ON (cdr.version = cvsm.ccmversion)
"version" doesn't sound very selective, so maybe you end up with
(almost) Carte
Hi,
+1 for the proposal.
Thanks for volunteering Konstantin!
Regards,
Roman
On Fri, Feb 11, 2022 at 3:00 PM Till Rohrmann wrote:
>
> +1 for a 1.14.4 release. The release-1.14 branch already includes 36 fixed
> issues, some of them quite severe.
>
> Cheers,
> Till
>
> On Fri, Feb 11, 2022 at
Congratulations!
Regards,
Roman
On Wed, Feb 16, 2022 at 5:22 PM Matthias Pohl wrote:
>
> Congratulations to all of you :)
>
> On Wed, Feb 16, 2022 at 4:04 PM Till Rohrmann wrote:
>
> > Congratulations! Well deserved!
> >
> > Cheers,
> > Till
> >
> > On Wed, Feb 16, 2022 at 2:51 PM Martijn Visse
Congratulations Martijn!
Regards,
Roman
On Fri, Mar 4, 2022 at 8:09 AM Sergey Nuyanzin wrote:
>
> Congratulations Martijn!
>
> On Fri, Mar 4, 2022 at 8:07 AM David Morávek wrote:
>
> > Congratulations Martijn, well deserved!
> >
> > Best,
> > D.
> >
> > On Fri, Mar 4, 2022 at 7:25 AM Jiangang L
Congratulations, David!
Regards,
Roman
On Fri, Mar 4, 2022 at 7:54 PM Austin Cawley-Edwards
wrote:
>
> Congrats David!
>
> On Fri, Mar 4, 2022 at 12:18 PM Zhilong Hong wrote:
>
> > Congratulations, David!
> >
> > Best,
> > Zhilong
> >
> > On Sat, Mar 5, 2022 at 1:09 AM Piotr Nowojski
> > wrote
+1 from myself (binding).
As there were no vetoes in more than 72hrs and three binding +1 the FLIP is
now accepted.
Thanks!
Regards,
Roman
On Wed, Feb 3, 2021 at 8:35 AM Arvid Heise wrote:
> FLIP looks good to me. +1
>
> On Wed, Feb 3, 2021 at 8:00 AM Piotr Nowojski
> wrote:
>
> > I'm carry
t;>
>> >> On Wed, Feb 10, 2021 at 2:08 PM Arvid Heise wrote:
>> >>> Congrats! Well deserved.
>> >>>
>> >>> On Wed, Feb 10, 2021 at 1:54 PM Yun Gao > >
>> >>> wrote:
>> >>>
>> >>>> Congratu
Thanks for your reply Stephan.
Yes, there is overlap between FLIP-151 and FLIP-158 as both
address incremental state updates. However, I think that FLIP-151 on top
of FLIP-158 increases efficiency by:
1. "Squashing" the changes made to the same key. For example, if some
counter was changed 10 tim
Hi everyone,
Please review and vote on the release candidate #1 for the version 1.12.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) On rescaling, we need to clarify which TM is responsible for releasing
> a handle, if they are mapped to multiple TMs. Otherwise we get
> double-delete calls. That isn't per se a problem, it is just a bit less
> efficient.
>
>
> Maybe we could think in that direction fo
Hi,
Yes, please go ahead. Thanks!
Regards,
Roman
On Mon, Feb 22, 2021 at 12:18 PM Maciej Obuchowski <
obuchowski.mac...@gmail.com> wrote:
> Hey, while working with the new 1.13 JDBC XA sink I had state restoration
> errors connected to XaSinkStateSerializer with it's implementation of
> SNAPSH
Congratulations!
Regards,
Roman
On Mon, Feb 22, 2021 at 12:22 PM Yangze Guo wrote:
> Congrats, Wei and Xingbo! Well deserved!
>
> Best,
> Yangze Guo
>
> On Mon, Feb 22, 2021 at 6:47 PM Yang Wang wrote:
> >
> > Congratulations Wei & Xingbo!
> >
> > Best,
> > Yang
> >
> > Rui Li 于2021年2月22日周一
of the upgrade of `commons-beanutils` from
>>> 1.9.3
>>> > to
>>> > > > 1.9.4, which had and maintained Apache 2.0 license.
>>> > > >
>>> > > > Piotrek
>>> > > >
>>> > > > pt
The artifacts removed.
Thanks everybody for taking part in the verification.
Regards,
Roman
On Tue, Feb 23, 2021 at 12:21 PM Roman Khachatryan wrote:
> Thanks Piotr,
>
> The RC-1 is therefore cancelled.
> I'll remove the artifacts and create a new RC once the issue is reso
Hi everyone,
The issue which caused the previous RC cancellation is now resolved [1].
There are two more issues that we'd like to include in 1.12.2 [2][3].
Yuan and I are going to prepare the next RC (#2) once they are resolved.
Please let us know if there are any other issues blocking the RC.
C
n we could also include FLINK-21030 [1]. We are about
>>> to
>>> merge this fix.
>>>
>>> [1] https://issues.apache.org/jira/browse/FLINK-21030
>>>
>>> Cheers,
>>> Till
>>>
>>> On Thu, Feb 25, 2021 at 4:13 PM Roman Khachatryan
&g
Hi everyone,
Please review and vote on the release candidate #1 for the version 1.12.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],
Hi everyone,
I'd like to propose to extract several "sub-lists" from our user mailing
list (u...@flink.apache.org).
For example,
- user-sql@flink.a.o (Python)
- user-statefun@f.a.o (StateFun)
- user-py@f.a.o. (SQL/TableAPI)
And u...@flink.apache.org will remain the main or "default" list.
That w
Hi everyone,
since the discussion [1] about FLIP-151 [2] seems to have reached a
consensus, I'd like to start a formal vote for the FLIP.
Please vote +1 to approve the FLIP, or -1 with a comment. The vote will be
open at least until Wednesday, Mar 3rd.
[1] https://s.apache.org/flip-151-discussio
t; >>>
> >>> Konstantin
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Mar 1, 2021 at 10:09 AM xiao...@ysstech.com
> >>>
> >>> wrote:
> >>>
> >>>> Hi Ro
n tell, except for some more tricky questions, the
>> turnaround
>> time for StateFun user questions has been ok so far.
>>
>> What do you think?
>>
>> Cheers,
>> Gordon
>>
>> On Mon, Mar 1, 2021 at 6:56 PM Roman Khachatryan
>> wrote:
&
Hi,
Thanks for the proposal Konstantin,
I like the ideas expressed there.
I am a bit concerned about the new issue type "Technical Debt". In contrast
to other issue types, it doesn't imply that someone will likely work on
that. So it can linger until the bot closes it.
Probably we need some rules
t contain any binaries.
> > > > > 3. Successfully Built the source with Maven.
> > > > > 4. Started a local Flink cluster, ran the streaming WordCount
> example
> > > > with
> > > > > WebUI,
> > > > > checked the ou
es and checksums
> - built from source
> - ran medium scale streaming and batch jobs (parallelism=1000) on a YARN
> cluster. checked output and logs.
> - the web PR looks good
>
> Thanks,
> Zhu
>
> Roman Khachatryan 于2021年3月2日周二 下午4:20写道：
>
> > Hi everyone,
>
I'm happy to announce that we have unanimously approved this release.
There are 7 approving votes, 5 of which are binding:
* Kurt Young
* Piotr Nowojski
* Roman Khachatryan
* Yu Li
* Zhu Zhu
There are no disapproving votes.
Thanks everyone!
Regards,
Roman
Thanks Robert,
That's a good idea, let's revisit it later.
Regards,
Roman
On Tue, Mar 2, 2021 at 3:40 PM Robert Metzger wrote:
> Thanks a lot for bringing up this idea Roman!
>
> After reading the initial proposal, I quite liked the idea, because it
> makes our life easier: We can only monito
PMC members.
> >
> > From the list you had seems like only 3 binding Votes, right?
> >
> >
> >
> > On Tue, Mar 2, 2021, 7:08 AM Roman Khachatryan wrote:
> >
> >> I'm happy to announce that we have unanimously approved this release.
> >&g
The Apache Flink community is very happy to announce the release of Apache
Flink 1.12.2, which is the second bugfix release for the Apache Flink 1.12
series.
Apache Flink® is an open-source stream processing framework for
distributed, high-performing, always-available, and accurate data streaming
ding)
> >
> > On Mon, Mar 1, 2021 at 10:12 AM Roman Khachatryan
> > wrote:
> >
> > > Hi everyone,
> > >
> > > since the discussion [1] about FLIP-151 [2] seems to have reached a
> > > consensus, I'd like to start a formal vote
Hi everyone,
The voting time for FLIP-151: Incremental snapshots for heap-based
state backend [1] has passed. I'm closing the vote now.
There were 5 +1 votes, 4 of which are binding:
- Piotr Nowojski (binding)
- Zhijiang (binding)
- David Anderson (non-binding)
- Yu Li (binding)
-
+1 (binding)
Regards,
Roman
On Fri, Mar 5, 2021 at 3:59 PM Till Rohrmann wrote:
>
> +1 (binding)
>
> Cheers,
> Till
>
> On Fri, Mar 5, 2021 at 2:43 PM Alexander Fedulov
> wrote:
>
> > Hi all,
> >
> > I would like to start a vote on FLIP-165 [1] which was discussed in [2] and
> > proposed to be
+1,
thanks for this improvement Konstantin!
Regards,
Roman
On Fri, Mar 26, 2021 at 8:49 AM Arvid Heise wrote:
>
> +1 from my side.
> Thanks for proposing!
>
> On Fri, Mar 26, 2021 at 8:40 AM Robert Metzger wrote:
>
> > +1 This is a very good improvement!
> >
> > Most likely we'll have to adju
Thanks for managing the release.
+1 (non-binding)
I've checked the artifacts:
- Verified checksums and GPG of artifacts in [2]
- Built the sources locally without errors
- Verified that the source archives do not contain any binaries
- Checked that all POM files point to the same version.
Regard
Thanks for raising this issue.
I agree with the above points.
One simple argument against labels is that they consume space in the
commit messages.
+1 to make labels optional
Regards,
Roman
On Thu, May 20, 2021 at 9:31 AM Robert Metzger wrote:
>
> +1 to Till's proposal to update the wording.
>
Hey Yuan, thanks for the proposal
I think Option 3 is the simplest to use and exposes less details than any other.
It's also consistent with the current way of configuring state
backends, as long as we treat change logging as a common feature
applicable to any state backend, like e.g.
state.backen
Congratulations!
Regards,
Roman
On Thu, Jun 17, 2021 at 5:56 AM Xingbo Huang wrote:
>
> Congratulations, Arvid!
>
> Best,
> Xingbo
>
> Yun Tang 于2021年6月17日周四 上午10:49写道：
>
> > Congratulations, Arvid
> >
> > Best
> > Yun Tang
> >
> > From: Yun Gao
> > Sent: Thurs
Congratulations!
Regards,
Roman
On Fri, Jun 18, 2021 at 4:40 AM Yu Li wrote:
>
> Congratulations, Xintong!
>
> Best Regards,
> Yu
>
>
> On Thu, 17 Jun 2021 at 15:23, Yuan Mei wrote:
>
> > Congratulations, Xintong :-)
> >
> > On Thu, Jun 17, 2021 at 11:57 AM Xingbo Huang wrote:
> >
> > > Congra
+1 (binding)
Regards,
Roman
On Mon, Jul 5, 2021 at 9:47 AM Chesnay Schepler wrote:
>
> +1 (binding)
>
> On 05/07/2021 09:45, Arvid Heise wrote:
> > +1 (binding)
> >
> > On Wed, Jun 30, 2021 at 5:56 PM Qingsheng Ren wrote:
> >
> >> Dear devs,
> >>
> >>
> >> As discussed in the thread[1], I’d lik
Congrats!
Regards,
Roman
On Wed, Jul 7, 2021 at 8:28 AM Qingsheng Ren wrote:
>
> Congratulations Yang!
>
> --
> Best Regards,
>
> Qingsheng Ren
> Email: renqs...@gmail.com
> On Jul 7, 2021, 2:26 PM +0800, Rui Li , wrote:
> > Congratulations Yang ~
> >
> > On Wed, Jul 7, 2021 at 1:01 PM Benchao
Congratulations!
Regards,
Roman
On Wed, Jul 7, 2021 at 8:24 AM Rui Li wrote:
>
> Congratulations Guowei!
>
> On Wed, Jul 7, 2021 at 1:01 PM Benchao Li wrote:
>
> > Congratulations!
> >
> > Dian Fu 于2021年7月7日周三 下午12:46写道：
> >
> > > Congratulations, Guowei!
> > >
> > > Regards,
> > > Dian
> > >
Congratulations Yuan!
Regards,
Roman
On Thu, Jul 8, 2021 at 6:02 AM Yang Wang wrote:
>
> Congratulations Yuan!
>
> Best,
> Yang
>
> XING JIN 于2021年7月8日周四 上午11:46写道：
>
> > Congratulations Yuan~!
> >
> > Roc Marshal 于2021年7月8日周四 上午11:28写道：
> >
> > > Congratulations, Yuan!
> > >
> > >
> > >
> > >
Hi everyone,
Thanks for the proposal and the discussion, I have some remarks:
(I'm not very familiar with the new Sink API but I thought about the
same problem in context of the changelog state backend)
1. Merging artifacts from multiple checkpoints would apparently
require multiple concurrent ch
Congratulations Fabian!
Regards,
Roman
On Mon, Nov 15, 2021 at 3:26 PM Dawid Wysakowicz wrote:
>
> Congratulations Fabian!
>
> On 15/11/2021 15:22, Marios Trivyzas wrote:
> > Congrats Fabian!
> >
> > On Mon, Nov 15, 2021 at 3:02 PM Francesco Guardiani
> >
> > wrote:
> >
> >> Congratulations Fa
Hi,
Thanks for the proposal Yun, I think that's a good idea and it could
solve the issue you mentioned (FLINK-26590) in many cases (though not all,
depending on deletion speed; but in practice it may be enough).
Having a separate interface (BulkDeletingFileSystem) would probably help in
increment
Hi everyone,
I'd like to discuss sharing RocksDB memory across slots as proposed in
FLINK-29928 [1].
Since 1.10 / FLINK-7289 [2], it is possible to:
- share these objects among RocksDB instances of the same slot
- bound the total memory usage by all RocksDB instances of a TM
However, the memory
r" in the example, how is the memory size of
> unmanaged part calculated?
> 3. For fine-grained-resource-management, the control
> of cpuCores, taskHeapMemory can still work, right? And I am a little
> worried that too many memory-about configuration options are complicated
&
the example, how is the memory size of
> unmanaged part calculated?
> 3. For fine-grained-resource-management, the control
> of cpuCores, taskHeapMemory can still work, right? And I am a little
> worried that too many memory-about configuration options are complicated
> for users to
gt; > >
> > > As an alternative, I'd suggest introducing a variant of
> > > RocksDBStateBackend, that shares memory across slots and does not use
> > > managed memory. This basically means the shared memory is not
> considered
> > as
> > > part of manage
Hi Thomas,
Thanks a lot for the analysis.
The first thing that I'd check is whether checkpoints became more frequent
with this commit (as each of them adds at least 500ms if there is at least
one not sent record, according to FlinkKinesisProducer.snapshotState).
Can you share checkpointing stati
ommit.
>
> It's probably good to take a look at the Kinesis producer. Is it really
> necessary to have 500ms sleep time? What's responsible for the ~30s
> duration in snapshotState?
>
> As things stand it doesn't make sense to use checkpoint intervals < 30s
ntTimeout(600_000);
>> checkpointConfig.setMaxConcurrentCheckpoints(1);
>> checkpointConfig.setFailOnCheckpointingErrors(true);
>>
>> The values marked bold when changed to *60_000* make the symptom
>> disappear. I meanwhile also verified that with the
Hi Thomas,
The fix is now merged to master and to release-1.11.
So if you'd like you can check if it solves your problem (it would be
helpful for us too).
On Sat, Aug 8, 2020 at 9:26 AM Roman Khachatryan
wrote:
> Hi Thomas,
>
> Thanks a lot for the detailed information.
>
>
+1 (binding)
Thanks for pushing this and updating the FLIP
Regards,
Roman
On Wed, Jun 26, 2024 at 9:27 AM Piotr Nowojski wrote:
> Thanks for pointing this out Zakelly. After the discussion on the dev
> mailing list, I have updated the `PathsCopyingFileSystem` to merge its
> functionalities wi
+1 (binding)
Regards,
Roman
On Wed, Jul 31, 2024 at 2:39 PM Rui Fan <1996fan...@gmail.com> wrote:
> +1(binding)
>
> Best,
> Rui
>
> Timo Walther 于2024年7月31日 周三17:47写道：
>
> > +1 (binding)
> >
> > Thanks for fixing this critical bug.
> >
> > Regards,
> > Timo
> >
> > On 31.07.24 09:51, Stefan Ric
+1,
Thanks for volunteering!
Regards,
Roman
On Mon, Nov 25, 2024 at 5:35 AM Zakelly Lan wrote:
> +1 for this
>
> Thanks for driving!
>
> Best,
> Zakelly
>
> On Mon, Nov 25, 2024 at 12:15 PM weijie guo
> wrote:
>
> > Thanks for driving this!
> >
> > +1 for this release and rm.
> >
> > Best re
Hi Piotr, thanks for the proposal!
I think this would be a very valuable addition to Flink as it would
simplify operations a lot
(disclaimer: we already use it in our internal Flink version)
I have a couple of remarks regarding the FLIP:
1. Should it list the events that would be emitted in the
Hi Piotr, thanks for the proposal,
I see the need for reporting child spans, however I have a couple of
questions about the proposed design:
1. Why do we give up on the idea of reporting child spans independently
from the parent? I couldn't find much details in the Rejected Alternatives
section
Hi Piotr, thanks for the proposal,
Can you please clarify
1. The scope of the variables added - is it only the last transformation?
Do I understand correctly, that chaining does NOT affect this scoping?
2. Is Python API going to be supported as well?
Thanks
Regards,
Roman
On Thu, Nov 7, 2024
Hi Piotr,
Adding OTel implementation makes sense, +1 for the proposal.
Thanks
Regards,
Roman
On Thu, Nov 7, 2024 at 2:37 PM Piotr Nowojski wrote:
> Hi all!
>
> I would like to open up for discussion a new FLIP-482 [1].
>
> Motivation
> FLIP-481 [2] is adding the EventReporter interface. Howe
;s used by Flink itself; or is very common.
>
> This introduced to fill in Otel's Body field
> `io.opentelemetry.api.logs.LogRecordBuilder#setBody`
>
> Best,
> Piotrek
>
> czw., 14 lis 2024 o 11:03 Roman Khachatryan napisał(a):
>
> > Hi Piotr, thanks for the pro
. Also AFAIR it's not clear how to convert a custom
> string into Otel's `Context` class . But I might be wrong with this last
> one.
>
> Best,
> Piotrek
>
>
> czw., 14 lis 2024 o 13:21 Roman Khachatryan napisał(a):
>
> > Hi Piotr, thanks for the proposal
1 - 100 of 368 matches
Mail list logo
