Raul,
Small comment from me.
>* As a Flink sink => inject data directly into a cache via a DataStreamer.
After reviews, IGNITE-813 is exactly this functionality.
-Roman
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
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
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 look
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
ike the idea of introducing parameter objects for backend creation.
Regards,
Roman
On Tue, Nov 7, 2023, 1:20 PM Piotr Nowojski wrote:
> (Fixing topic)
>
> wt., 7 lis 2023 o 09:40 Piotr Nowojski napisał(a):
>
> > Hi all!
> >
> > I would like to start a discussion on a follo
hould be used.
How about dropping it from the API and always using min, max, sum, avg? I
think we're interested in these aggregations for all the metrics, and there
is no penalty for reporting all of them because it's only for
initialization.
Regards,
Roman
On Mon, Nov 20, 2023, 8:42 AM
+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 e
+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 W
+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
+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,
> &
ote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> I would like to start the vote for FLIP-76 [1], which is discussed and
> >>>> reached a consensus in the discussion thread [2].
> >>>>
> >>>> The vote will be open until March. 13th (72h), unless there is an
> >>> objection
> >>>> or not enough votes.
> >>>>
> >>>> Thanks,
> >>>> Arvid
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-76%3A+Unaligned+Checkpoints
> >>>> [2]
> >>>>
> >>>>
> >>>
> >>
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-76-Unaligned-checkpoints-td33651.html
> >>>>
> >>>
> >>
>
>
--
Regards,
Roman
state
- need to maintain meta table
5. Simplicity: about the same
XA: more corner cases
WAL: state and meta table management
Both wrap writes into transactions
6. Testing - WAL preferable
XA requires MVVC and proper XA support (no jars needed for derby)
--
Regards,
Roman
ization
of various aspects independently and eventually support of more use cases.
Any feedback welcome.
[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-94%3A+Rework+2-phase+commit+abstractions
--
Regards,
Roman
* and
hope to see as many of you as possible in two months!
Thanks,
Roman.
Hi folks.
I want to do something for Flink. As the first step I have started doing
https://issues.apache.org/jira/browse/FLINK-5002, could you assign it for me in
JIRA.
Thanks.
was a great success this year and we hope to make it an even
bigger success in 2017.
Besides -- FOSDEM is the biggest gathering of open source
developers on the face of the earth -- don't miss it!
Thanks,
Roman.
P.S. If you have any questions -- please email me directly and
see you all in Brussels!
+1 (non-binding).
It would be a great improvement, thanks for the effort!
Regards,
Roman
On Tue, Oct 20, 2020 at 4:49 PM Steven Wu wrote:
> +1 (non-binding).
>
> Some of our users have asked for this tradeoff of consistency over
> availability for some cases.
>
> On Mon, Oc
Hey Austin,
I assigned the ticket,
that would be great if you could fix it!
Regards,
Roman
On Thu, Oct 22, 2020 at 5:08 PM Austin Cawley-Edwards <
austin.caw...@gmail.com> wrote:
> Hey Roman,
>
> Sorry to miss this -- thanks for the confirmation and making the ticket.
> I&#x
ental checkpoints. This FLIP
aims to add initial support for them.
[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-151%3A+Incremental+snapshots+for+heap-based+state+backend
Any feedback highly appreciated.
Regards,
Roman
Hi,
I'd like FLINK-20079 [1] to be merged into 1.11 and included in 1.11.3.
[1] https://issues.apache.org/jira/browse/FLINK-20079
Regards,
Roman
On Tue, Nov 10, 2020 at 8:21 AM Xintong Song wrote:
> Thanks for the notice, Dian.
>
> Thank you~
>
> Xintong Song
>
>
&
FLIP document.
Thanks!
Regards,
Roman
On Tue, Nov 10, 2020 at 12:04 AM Stefan Richter
wrote:
> Hi,
>
> Very happy to see that the incremental checkpoint idea is finally becoming
> a reality for the heap backend! Overall the proposal looks pretty good to
> me. Just wanted to po
+1 for the migration
(I agree with Dawid, for me the most important benefit is better support of
parameterized tests).
Regards,
Roman
On Mon, Nov 30, 2020 at 9:42 PM Arvid Heise wrote:
> Hi Till,
>
> immediate benefit would be mostly nested tests for a better test structure
d for jobs about to finish).
3. Option 3 assumes that the state of a finished task is not used. That's
true for operator state, but what about channel state (captured by
unaligned checkpoint)? I think it still has to be sent downstream which
invalidates this Option.
Regards,
Roman
On Thu, Jan
I wonder how significantly this waiting for EoP from every input will
delay performing the first checkpoint by B after becoming a new source.
This may in turn impact exactly-once sinks and incremental checkpoints.
Maybe a better option would be to postpone JM notification from source
until it's E
Hi,
I'm not sure whether it's https://issues.apache.org/jira/browse/FLINK-20654 or
a new issue but I agree it shouldn't block 1.12.1.
Regards,
Roman
On Mon, Jan 11, 2021 at 10:30 AM Arvid Heise wrote:
> Hi Xingbo,
>
> This ticket is actually about
> https://issues.a
task thread wouldn't add much complexity, though I'm not sure
if it would cause any problems.
> do you think it would be ok for us to view it as an optimization and
postpone it to future versions ?
I think that's a good idea.
Regards,
Roman
On Mon, Jan 11, 2021 at 11:03 AM Y
.
Regards,
Roman
On Thu, Jan 14, 2021 at 10:28 AM Till Rohrmann wrote:
> Thanks for volunteering as the release managers for the 1.13 release Guowei
> and Dawid. I'd also be in favour of targeting the end of March as the
> feature freeze date.
>
> I've created a 1.13 wik
rent exchange types, WDYT?
[1]
https://issues.apache.org/jira/browse/FLINK-24035
Regards,
Roman
On Tue, Dec 27, 2022 at 4:12 AM Yuxin Tan wrote:
> Hi, Weihua
>
> Thanks for your suggestions.
>
> > 1. How about reducing ExclusiveBuffersPerChannel to 1 first when the
> total
proposed changes?
Regards,
Roman
On Wed, Dec 28, 2022 at 12:19 PM JasonLee <17610775...@163.com> wrote:
> Hi Yuxin
>
>
> Thanks for the proposal, big + 1 for this FLIP.
>
>
>
> It is difficult for users to calculate the size of network memory. If the
> setting is too
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
>
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, F
other setups, where the job should not be stopped at all, the user can
always set it to 0.
Regards,
Roman
On Tue, Feb 28, 2023 at 12:58 PM Maximilian Michels wrote:
> Hi David,
>
> Thanks for the update! We consider using the new declarative resource
> API for autoscaling. Currently
+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)
> >
+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:
]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-415
%3A+Introduce+a+new+join+operator+to+support+minibatch
--
Best regards,
Roman Boyko
e.: ro.v.bo...@gmail.com
m.: +79059592443
telegram: @rboyko
Hi Flink Community,
I tried to describe my idea about minibatch for TopNFunction in this doc -
https://docs.google.com/document/d/1YPHwxKfiGSUOUOa6bc68fIJHO_UojTwZEC29VVEa-Uk/edit?usp=sharing
Looking forward to your feedback, thank you
On Tue, 19 Mar 2024 at 12:24, Roman Boyko wrote:
> He
google.com/document/d/1YPHwxKfiGSUOUOa6bc68fIJHO_UojTwZEC29VVEa-Uk
<https://docs.google.com/document/d/1YPHwxKfiGSUOUOa6bc68fIJHO_UojTwZEC29VVEa-Uk/edit?usp=sharing>
[2]
https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/sql/queries/topn/#no-ranking-output-optimization
--
Bes
9VVEa-Uk
<https://docs.google.com/document/d/1YPHwxKfiGSUOUOa6bc68fIJHO_UojTwZEC29VVEa-Uk/edit?usp=sharing>
--
Best regards,
Roman Boyko
e.: ro.v.bo...@gmail.com
m.: +79059592443
telegram: @rboyko
On Thu, 28 Mar 2024 at 09:41, shuai xu wrote:
> Hi, Roman
>
> Thanks for your proposal. I think t
+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
+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 discus
found in document [2] (under Nexmark subtitle)
Looking forward to your feedback.
[1]
https://github.com/rovboyko/flink/tree/feature/topn-output-buffer
[2]
https://docs.google.com/document/d/1YPHwxKfiGSUOUOa6bc68fIJHO_UojTwZEC29VVEa-Uk
--
Best regards,
Roman Boyko
e.: ro.v.bo...@gmail.com
m
took part in
some steps of this effort).
Regards,
Roman
On Mon, Apr 22, 2024, 08:11 yue ma wrote:
> Hi Flink devs,
>
> I would like to start a discussion on FLIP-447: Upgrade FRocksDB from
> 6.20.3 to 8.10.0
>
>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-44
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,
> > Yunho
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
> > pr
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
+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 th
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
> Y
to the schema proposed by Alexander.
Qingshen Ren, please correct me if I'm not right and all these facilities
might be simply implemented in your architecture?
Best regards,
Roman Boyko
e.: ro.v.bo...@gmail.com
On Wed, 4 May 2022 at 21:01, Martijn Visser
wrote:
> Hi everyone,
>
>
; caching and metrics.
>
> Best regards,
>
> Martijn Visser
> https://twitter.com/MartijnVisser82
> https://github.com/MartijnVisser
>
>
> On Thu, 5 May 2022 at 13:58, Roman Boyko wrote:
>
> > Hi everyone!
> >
> > Thanks for driving such a va
hink the semantics of
> > >> >
which is doable but
not trivial (which I think supports "reverse API option").
7. I think it would be helpful to list file systems / object stores
that support "fast" copy (ideally with latency numbers).
Regards,
Roman
On Mon, Nov 22, 2021 at 9:24 AM Yun Gao wrote:
>
&g
eed this anyway if we choose to re-upload files once the
job is running.
The new checkpoint must be formed by re-uploaded old artifacts AND
uploaded new artifacts.
Regards,
Roman
On Mon, Nov 22, 2021 at 12:42 PM Dawid Wysakowicz
wrote:
>
> @Yun
>
> I think it is a go
herefore be weighted against those
operational disadvantages (given that the number of checkpoints to
wait is bounded in practice).
Regards,
Roman
On Mon, Nov 22, 2021 at 5:05 PM Dawid Wysakowicz wrote:
>
> There is one more fundamental issue with either of your two proposals
> that&#x
o way to find out when the shared
state can be deleted; it can't be inferred from which checkpoints are
subsumed, and which are not, as future checkpoints might still be
using that state.
Regards,
Roman
On Tue, Nov 23, 2021 at 1:37 PM Piotr Nowojski wrote:
>
> Hi,
>
> I'm no
erving handle immutability then we'll
probably have to rebuild the whole task state snapshot.
(depending on how we approach RocksDB re-uploading, it might not be
relevant though)
Regards,
Roman
On Tue, Nov 23, 2021 at 4:06 PM Dawid Wysakowicz wrote:
>
> I think I know where the confu
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
rve the current behavior (no claim
and no duplicate)?
And I still think it would be nice to list object stores which support
duplicate operation.
Regards,
Roman
On Fri, Nov 26, 2021 at 10:37 AM Konstantin Knauf wrote:
>
> Hi Dawid,
>
> sounds good, specifically 2., too.
>
> Best,
+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
it has a rather high price (bursty workload with
> high latency). Ideally, we can keep the compaction asynchronously...
Yes, that would be something like a WAL. I agree that it would have a
different set of trade-offs.
Regards,
Roman
On Mon, Nov 29, 2021 at 3:33 PM Arvid Heise wrote:
>&g
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
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
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 jd
end up with
(almost) Cartesian product?
Regards,
Roman
On Wed, Jan 12, 2022 at 11:06 AM Ronak Beejawat (rbeejawa)
wrote:
>
> Hi Team,
>
> I was trying to implement flink sql api join with 2 tables it is throwing
> error OutOfMemoryError: Java heap space . PFB screenshot for flink
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
>
>
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
> >
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.
> >
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
> >
>
ighly appreciated!
Regards,
Roman
in Flink code.
And for cases without such a file, we could have a default one on the
classpath with all substitutions defined (and then merge everything from
the user-supplied file).
[1] https://issues.apache.org/jira/browse/FLINK-19520
Regards,
Roman
On Mon, Jan 18, 2021 at 11:11 AM Ingo Bürk
+1 (non-binding)
Thanks for driving the FLIP!
Regards,
Roman
On Tue, Jan 19, 2021 at 2:58 AM Guowei Ma wrote:
> +1 non-binding
> Best,
> Guowei
>
>
> On Fri, Jan 15, 2021 at 10:56 PM Yun Gao
> wrote:
>
> >
> > Hi all,
> >
> > I would like to
it now.
I guess you are right. We should probably start release planning before the
previous one is completed. So maybe 1.14 :)
I think if anyone else is interested we can continue discussion in a
separate thread.
Thanks again for driving this effort!
Regards,
Roman
On Mon, Jan 18, 2021 at 3
Hi,
I think having two Deprecated annotations (Flink and Java) may be confusing.
One alternative is to combine standard annotation with mandatory Javadocs
tags (checked with checkstyle).
And starting from Java 9 it has "since" and "forRemoval" arguments.
Regards,
Roman
On
uot; (s3.access-key → FLINK_CONFIG_S3_ACCESS__KEY) you mentioned earlier?
Regards,
Roman
On Mon, Jan 25, 2021 at 6:48 PM Till Rohrmann wrote:
> The problem I see with $FLINK_PROPERTIES is that this is only supported by
> Flink's Docker entrypoint.sh. In fact this variable was i
approach with
passing individual variables.
Regards,
Roman
On Tue, Jan 26, 2021 at 12:54 PM Chesnay Schepler
wrote:
> I think we have to assume that some user has a custom config option that
> uses underscores.
>
> That said, we can probably assume that no one uses other special
> ch
In the future, we can consider adding smth like ConfigOption.withEnvVar for
some (most popular) options.
However, escaping is still not clear to me: how would kv-pairs be
separated? What if such a separator is in the value itself? What if '=' is
in the value?
Or am I missing something?
R
iables. But
> for Yarn and K8s deployment(both standalone on K8s and native), we
already have such a file, which is shipped from client
> or mounted from a ConfigMap.
Can we have a default file in Flink on the classpath with keys already
mapped to env vars? (as I wrote in the very beginning).
R
ide.
> Did we consider whether approach 3 is good enough?
Does this mean putting all system properties into the Configuration eagerly?
> Is approach 4 a viable option after all? I think we should continue the
discussion around the questions that were brought up.
I think it's still viable
publish it soon (logging only), so all
interested users will be able to try it out.
Regards,
Roman
On Thu, Jan 28, 2021 at 1:58 PM Yuan Mei wrote:
> Big +1 onto this FLIP!
>
> Great to see it is stepping forward since this idea is discussed for quite
> a while. :-)
>
> 1. I tot
K/FLIP-158%3A+Generalized+incremental+checkpoints
[2]
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-158-Generalized-incremental-checkpoints-td47902.html
Regards,
Roman
+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
> wrot
Many thanks to all of you!
Regards,
Roman
On Wed, Feb 10, 2021 at 7:12 PM Matthias Pohl
wrote:
> Congratulations, Roman! :-)
>
> On Wed, Feb 10, 2021 at 3:23 PM Kezhu Wang wrote:
>
>> Congratulations!
>>
>> Best,
>> Kezhu Wang
>>
>>
>&
ery to actually remove data from the previous snapshot.
In FLIP-158 it is again similar: ChangelogStateBackend has to encode
removal operations and send them to StateChangelog (though no additional
data structure is required).
Regards,
Roman
On Thu, Feb 11, 2021 at 4:28 PM Stephan Ewen wrote:
lease-1.12.2-rc1" [5],
* website pull request listing the new release and adding announcement blog
post [6].
The vote will be open for at least 72 hours. It is adopted by majority
approval, with at least 3 PMC affirmative votes.
Regards,
Roman
[1]
https://issues.apache.org/jira/secure/Releas
/barriers.
To limit FLIP-158 scope I'd implement the last change and
limit max-concurrent-checkpoint to 1.
Regards,
Roman
On Tue, Feb 16, 2021 at 10:00 AM Stephan Ewen wrote:
> Thanks for clarifying.
>
> Concerning the JM aborted checkpoints and state handles: I was thinking
>
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
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!
> >
> >
Thanks Piotr,
The RC-1 is therefore cancelled.
I'll remove the artifacts and create a new RC once the issue is resolved.
Regards,
Roman
On Tue, Feb 23, 2021 at 11:57 AM Piotr Nowojski
wrote:
> Ops, sorry I've linked the wrong issue in the previous email. This is the
> corr
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
he RC.
Currently, the dashboard doesn't show any blockers [4].
[1] https://issues.apache.org/jira/browse/FLINK-21453
[2] https://issues.apache.org/jira/browse/FLINK-21490
[3] https://issues.apache.org/jira/browse/FLINK-21452
[4] https://s.apache.org/flink-1.12.2-blockers
Regards,
Roman
On M
from e9af362f0caa16e75e66aa1403c62666e77f98f0.
[1] https://issues.apache.org/jira/browse/FLINK-21030
Regards,
Roman
On Fri, Feb 26, 2021 at 1:43 PM Matthias Pohl
wrote:
> There's a test instability which I assume is caused by FLINK-21028 [1]. I
> created FLINK-21515 [2] to cover this issue.
-rc2
[6] https://github.com/apache/flink-web/pull/418
Regards,
Roman
default" list.
That would improve the quality and speed of the answers and allow
developers to concentrate on the relevant topics.
At the downside, this would lessen the exposure to the various Flink areas
for lists maintainers.
What do you think?
Regards,
Roman
p-151-discussion
[2]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-151%3A+Incremental+snapshots+for+heap-based+state+backend
Regards,
Roman
the wrong topic.
But splitting doesn't change anything here: if a SQL question for example
is asked on StateFun ML then
we still have the options above (plus an option to redirect user to the
other list).
Regards,
Roman
On Mon, Mar 1, 2021 at 11:30 AM Dawid Wysakowicz
wrote:
> As others I
bit different
context: no other sub-lists and no data about the list.
Regards,
Roman
On Mon, Mar 1, 2021 at 2:59 PM Igal Shilman wrote:
> Hi Roman,
>
> Regarding StateFun having a separate mailing list, I'm ok with it going
> either-way, however when we first contributed
> the proj
ly we need some rules requiring a person opening such a ticket to
have an intention to work on it in the near future?
Another approach would be some wiki space.
As for the trivial priority, I would remove it and (use labels where
appropriate) as you suggested.
Regards,
Roman
On Mon, Mar 1, 2
Hi everyone,
+1 (binding)
I've verified the checksums and the source distribution with maven verify.
Regards,
Roman
On Tue, Mar 2, 2021 at 7:29 AM Kurt Young wrote:
> +1 (binding)
>
> - We mainly checked the patch of FLINK-20663 [1] and confirmed there is no
> OutOfMa
Hi Konstantin,
I think we should try it out.
Even if tickets don't work well it can be a good step towards managing
technical debt in some other way, like wiki.
Thanks!
Regards,
Roman
On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz
wrote:
> I'd be fine with dropping the "
Thank you all for helping to verify and test the RC!
The vote has lasted for more than 72 hours and has enough approvals.
I will finalize the vote result soon in a separate email.
Regards,
Roman
On Tue, Mar 2, 2021 at 10:33 AM Zhu Zhu wrote:
> +1 (binding)
> - checked signatur
1 - 100 of 422 matches
Mail list logo
