agreement in the discussion thread
please,
Kind regards, David.
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
in case it is misleading?
Kind regards, David.
From: Martijn Visser
Date: Monday, 23 October 2023 at 16:18
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: Backport strategy
Hi David,
The policy is that the current and and previous minor release are
supported, and it's documented at
https
of 1.15 1.16 1.17.
WDYT?
Kind regards, David.
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
could be extended to
include links to this information. I am happy to do that as part of this pr ,
if needed, if I can be supplied the links. I think this pr should be merged
asap, so subsequent pom file changes use the Maven variables.
WDYT
Kind regards, David.
Unless otherwise stated above
pache/flink/blob/d78d52b27af2550f50b44349d3ec6dc84b966a8a/flink-core/src/main/java/org/apache/flink/core/fs/FileSystem.java#L695
>
> [2]
> https://github.com/apache/flink/blob/d78d52b27af2550f50b44349d3ec6dc84b966a8a/flink-core/src/main/java/org/apache/flink/core/fs/FileSystem.java#L706
Congratulations Ron!
From: Jark Wu
Date: Sunday, 15 October 2023 at 18:57
To: dev
Cc: ron9@gmail.com
Subject: [EXTERNAL] [ANNOUNCE] New Apache Flink Committer - Ron Liu
Hi, everyone
On behalf of the PMC, I'm very happy to announce Ron Liu as a new Flink
Committer.
Ron has been
thread information is nice to drill down into specific
parts of the Flink application, e.g. the flame graph lets me ignore the
many other tasks running on TM & drill down into just the Source threads,
when debugging a Source issue.
Kind regards,
David
On Fri, Oct 13, 2023 at 1:45 AM Rui Fa
for them.
On balance, as I am risk averse, I would suggest delaying this to v2 as Jing
has proposed. This is a cleaner API, is there a demand for this in a dot
version? If the community think this is too risk averse, then we could go with
1.19.
WDYT?
Kind regards, David.
From: Jing Ge
david radley created FLINK-33269:
Summary: light and dark scss files do not have apache licenses at
the top.
Key: FLINK-33269
URL: https://issues.apache.org/jira/browse/FLINK-33269
Project: Flink
using git actions, so that
if an approved approver indicates a pr is good then the raiser can merge – this
would give us granularity on write access – PyTorch follows this sort of
process.
kind regards, David.
From: Martijn Visser
Date: Thursday, 12 October 2023 at 10:32
To: dev
(such as network access) – then there could be retries. I agree
we should not be trying to create code now for an implementation consideration
that is not there yet,
+1 from me ,
Kind regards, David.
From: Zakelly Lan
Date: Wednesday, 11 October 2023 at 04:25
To: dev@flink.apache.org
Hi,
I notice that the latest version in olm of the operator is 1.5. I plan to run
the scripts to publish the 1.6 Flink operator to olm,
Kind regards, David.
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO
a new class
ValueState2– that is used internally with the cleaned up Exceptions, but still
expose the old class and Exceptions for existing external applications. I guess
new applications could use the new ValueState2 .
What do you think?
Kind regards, David.
From: David Radley
Date
be appropriate for
those cases; and be part of the contract with the caller. Can we be sure that
there is no possibility that the state will become available; if so then I
agree that a runtime Exception is appropriate. What do you think?
Kind regards, David.
From: Zakelly Lan
Date: Monday, 9
that there is no regression like this,
Kind regards, David.
From: Martijn Visser
Date: Thursday, 5 October 2023 at 21:39
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: [ANNOUNCE] Release 1.18.0, release candidate #0
Hi David,
It’s a deliberate choice to decouple the connectors. We shouldn’t block
Flink 1.18
built outside of the Flink repo. We may want to not include the Flink
core version in the connector – or we might end up wanting to release a Kafka
connector when there are no changes just to have a match with the Flink core
version.
Kind regards, David.
From: Jing Ge
Date: Wednesday, 4
?
Kind regards, David.
From: Jing Ge
Date: Wednesday, 27 September 2023 at 15:11
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: [ANNOUNCE] Release 1.18.0, release candidate #0
Hi Folks,
@Ryan FYI: CI passed and the PR has been merged. Thanks!
If there are no more other concerns, I
suggest we also remove the connector/kafka
component from the core flink repo – so no new prs come in with it.
What do you think?
Kind regards, David.
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41
– I would think that
component ownership helps scope the subset of prs to review / merge.
Kind regards, David.
From: Ryan Skraba
Date: Wednesday, 4 October 2023 at 15:09
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: FW: RE: Close orphaned/stale PRs
Hey, this has been
, it's a significant
improvement either way. This was just the first thing that I thought about
after reading the flip.
Best,
D.
On Tue, Oct 3, 2023 at 2:10 PM xiangyu feng wrote:
> Hi David,
>
> Thx for your feedback.
>
> First of all, for keeping some spare resources around, do
Hi,
To add I agree with Martijn’s insights; I think we are saying similar things.
To progress agreed upon work, and not blanket close all stale prs,
Kind regards, David.
From: David Radley
Date: Wednesday, 4 October 2023 at 10:59
To: dev@flink.apache.org
Subject: [EXTERNAL] RE: Close
issues that new contributors to
choose from
I am happy to help to improve – once we have consensus,
Kind regards, David.
From: Venkatakrishnan Sowrirajan
Date: Wednesday, 4 October 2023 at 00:36
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: Close orphaned/stale PRs
Gentle ping to s
, with errors and warnings
if the content is such that the user would need to manually fix up the file.
If there are minimal user fixups, we should consider automatically migrating
the config file to the new format,
Kind regards, David.
From: Chesnay Schepler
Date: Tuesday, 3 October 2023 at 11
High Availability you have to set the high-availability
mode to zookeeper, configure a ZooKeeper quorum and set up a masters file with
all JobManagers hosts and their web UI ports.”
Have I missed anything here? What are your thoughts?
Kind regards, David.
Unless otherwise stated
Hi Maomao,
I wonder whether it would make sense to take a stab at consolidating the S3
filesystems instead and introduce a native one. The whole Hadoop wrapper
around the S3 client exists for legacy reasons, and it adds complexity and
probably an unnecessary performance penalty.
If you take a
H Xiangyui,
The sentiment of the FLIP makes sense, but I keep wondering whether this is
the best way to think about the problem. I assume that "interactive session
cluster" users always want to keep some spare resources around (up to a
configured threshold) to reduce cold start instead of
Hello Yuepeng,
The FLIP reads sane; nice work! To re-phrase my understanding:
The problem you're trying to solve only exists in complex graphs with
different per-vertex parallelism. If the parallelism is set globally
(assuming the pipeline has roughly even data skew), the algorithm could
make
, so I can proceed,
kind regards, David.
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
david radley created FLINK-33165:
Summary: Flink UI stack trace popup continually displayed when a
job is deleted
Key: FLINK-33165
URL: https://issues.apache.org/jira/browse/FLINK-33165
Project
david radley created FLINK-33159:
Summary: Use the variables for java and Maven version checks in
the pom file
Key: FLINK-33159
URL: https://issues.apache.org/jira/browse/FLINK-33159
Project: Flink
also to have this asset -> process ->
asset pattern for each of the steps in the job. If this is present, please
could you point me to it,
Kind regards, David.
From: David Radley
Date: Tuesday, 19 September 2023 at 16:11
To: dev@flink.apache.org
Subject: [EXTERNAL] RE: [DISCUSS]
Hi,
I notice that there is an experimental lineage integration for Flink with
OpenLineage https://openlineage.io/docs/integrations/flink . I think this
feature would allow for a superior Flink OpenLineage integration,
Kind regards, David.
From: XTransfer
Date: Tuesday, 19 September
Hi,
I like the proposal from Martijn. Having an ‘archived’ area for the older
material would make sense so users on the older versions can still access the
content for upgrade, keeping maybe the latest 3 releases in active table,
Kind regards, David.
From: Martijn Visser
Date: Friday, 15
:
[3.1.1,)
${target.java.version}
Is there a reason to have these 2 versions of Maven enforcers or can we use one
Maven enforcer that will apply to all cases?
Kind regards, David.
From: David Radley
Date: Friday, 15 September 2023 at 11:47
To: dev
Hi again,
I have just checked and you already enforcer have the enforcer for this in
master. I guess the only extra piece would be to put out a warning for java 8
indicating it is deprecated – I could look at that in a Jira,
Kind regards, David.
From: David Radley
Date: Friday, 15
it I deprecated. Error for java levels less than 8.
If this ok I will raise a Jira to add this Maven and potentially java checking
to the build,
Kind regards, David.
From: Sergey Nuyanzin
Date: Thursday, 14 September 2023 at 16:07
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: Inconsistent
the docs to make them consistent,
Kind regards, David
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
+1 since there is an alternative, more complete implementation available
Best,
D.
On Sat, Sep 2, 2023 at 12:07 AM David Anderson wrote:
> +1
>
> Keeping the legacy implementation in place is confusing and encourages
> adoption of something that really shouldn't be used.
>
>
Hi Tawfik,
It's exciting to see any ongoing research that tries to push Flink forward!
The get the discussion started, can you please your paper with the
community? Assessing the proposal without further context is tough.
Best,
D.
On Mon, Sep 4, 2023 at 4:42 PM Tawfek Yasser Tawfek
wrote:
>
+1
Keeping the legacy implementation in place is confusing and encourages
adoption of something that really shouldn't be used.
Thanks for driving this,
David
On Fri, Sep 1, 2023 at 8:45 AM Jing Ge wrote:
>
> Hi Wencong,
>
> Thanks for your clarification! +1
>
> Best regards,
AFAIK Apache Beam also used acummulators for metric collection, which is
indeed a major use case.
I’m not convinced that MetricGroup is fuĺly replacing what acummulators
have to offer though; OperatorCoordinators might be able to rplace
remaining capabilities, but this need bit more thoughts, the
.
David
[1] https://issues.apache.org/jira/browse/FLINK-15672
[2] https://issues.apache.org/jira/browse/FLINK-5339
On Mon, Aug 21, 2023 at 4:21 AM Y SREEKARA BHARGAVA REDDY
wrote:
>
> Hi Team,
>
> Does any one did integration flink 1.10 with log4j2 instead of log4j1.
>
> If
Dong,
Thank you for the careful analysis of my proposal. Your conclusions
make sense to me.
David
On Mon, Jul 24, 2023 at 8:37 PM Dong Lin wrote:
>
> Hi David,
>
> Thank you for the detailed comments and the suggestion of this alternative
> approach.
>
> I agree with you
before watermarking begins, followed by
an unbounded component.
I think this alternative handles use cases like processing-time
temporal join rather nicely, without requiring any changes to
watermarks or the core runtime.
David
On Thu, Jun 29, 2023 at 1:39 AM Martijn Visser wrote:
>
> H
ut you shouldn't do that in the first place.
That sounds great; let's go ahead and outline this in the FLIP.
Best,
D.
On Tue, Jul 4, 2023 at 12:30 PM Etienne Chauchot
wrote:
> Hi all,
>
> Thanks David for your feedback. My comments are inline
>
> Le 04/07/2023 à 09:16,
I've left some comments on the PR.
On Tue, Jul 4, 2023 at 9:20 AM Martijn Visser
wrote:
> Hi Hong,
>
> Given that this changes the REST API, which is a public interface, I'm
> wondering if this shouldn't first have had a (small) FLIP if I follow the
> guidelines from the overview page [1].
>
>
:11 AM David Morávek wrote:
> The FLIP reads sane to me. I'm unsure about the default values, though; 5
> minutes of wait time between rescales feels rather strict, and we should
> rethink it to provide a better out-of-the-box experience.
>
> I'd focus on newcomers trying AS /
The FLIP reads sane to me. I'm unsure about the default values, though; 5
minutes of wait time between rescales feels rather strict, and we should
rethink it to provide a better out-of-the-box experience.
I'd focus on newcomers trying AS / Reactive Mode out. They will struggle if
they add new
at 8:49 AM David Morávek wrote:
> The vote closes within 6 hours and, as for now, there was no vote. This
>> is a very short FLIP, that takes a few minutes to read.
>>
>
> Maybe because there should have been a dedicated voting thread (marked as
> [VOTE]), this one was h
>
> The vote closes within 6 hours and, as for now, there was no vote. This
> is a very short FLIP, that takes a few minutes to read.
>
Maybe because there should have been a dedicated voting thread (marked as
[VOTE]), this one was hidden and hard to notice.
We should restart the vote with
Hi Hong,
Thanks for starting the discussion.
seems to be using the cached version of the entire Execution graph (stale
> data), when it could just use the CheckpointStatsCache directly
CheckpointStatsCache is also populated using the "cached execution graph,"
so there is nothing to gain from
Hi,
Thanks for the FLIP! Data lineage is an important problem to tackle.
Can you please expand on how this is planned to be wired into the
JobManager? As I understand, the listeners will be configured globally (per
cluster), so this won't introduce a new code path for running per-job /
+1 these things already popped up during the initial review by Chesnay, but
I wasn't able to visualize them in a way that didn't look completely awful
:)
I hope that someone will be able to pick this up.
Best,
D.
On Fri, May 19, 2023 at 1:30 PM Jing Ge wrote:
> Hi David,
>
&g
Hi Everyone,
In FLINK-31471, we've introduced new "in-place rescaling features" to the
Web UI that show up when the scheduler supports FLIP-291 REST endpoints.
I expect this to be a significant feature for user education (they have an
easy way to try out how rescaling behaves, especially in
David Anderson created FLINK-32099:
--
Summary: create flink_data volume for operations playground
Key: FLINK-32099
URL: https://issues.apache.org/jira/browse/FLINK-32099
Project: Flink
Issue
Chesnay, thank you for all your hard work on this!
David
On Fri, May 12, 2023 at 4:03 PM Chesnay Schepler wrote:
>
>
> What happened?
>
> I have just merged the last commits to properly support Maven 3.3+ on
> the Flink master branch.
>
> mvnw and CI have been up
> > > >>>>>
> > > >>>>> Can we also prevent Junit4 usage in new code by this way？Because
> > > >>>> currently
> > > >>>>> we are aiming to migrate our codebase to JUnit 5.
> > > >>>>&g
Hi,
Great to see this topic moving forward; I agree it's long overdue.
I keep thinking about 2.0 as a chance to eliminate things that didn't work,
make the feature set denser, and fix rough edges and APIs that hold us back.
Some items in the doc (Key Features section) don't tick these boxes for
Hi Eric,
this sounds reasonable, there are definitely cases where you need to limit
sink parallelism for example not to overload the storage or limit the
number of output files
+1
Best,
D.
On Sun, Apr 23, 2023 at 1:09 PM Weihua Hu wrote:
> Hi, Eric
>
> Thanks for bringing this discussion.
>
Hi Everyone,
A long time ago, the community decided not to use Mockito-based tests
because those are hard to maintain. This is already baked in our Code Style
and Quality Guide [1].
Because we still have Mockito imported into the code base, it's very easy
for newcomers to unconsciously introduce
Congratulations, Qingsheng, well deserved!
Best,
D.
On Fri 21. 4. 2023 at 16:41, Feng Jin wrote:
> Congratulations, Qingsheng
>
>
>
> Best,
> Feng Jin
>
> On Fri, Apr 21, 2023 at 8:39 PM Mang Zhang wrote:
>
> > Congratulations, Qingsheng.
> >
> >
> >
> >
> >
> > --
> >
> > Best regards,
Congratulations, Leonard, well deserved!
Best,
D.
On Fri 21. 4. 2023 at 16:40, Feng Jin wrote:
> Congratulations, Leonard
>
>
>
> Best,
> Feng Jin
>
> On Fri, Apr 21, 2023 at 8:38 PM Mang Zhang wrote:
>
> > Congratulations, Leonard.
> >
> >
> > --
> >
> > Best regards,
> > Mang Zhang
> >
Thanks for the update!
+1 (binding)
Best,
D.
On Thu, Apr 20, 2023 at 9:50 AM Piotr Nowojski wrote:
> Hi,
>
> I see that the FLIP has been updated, thanks Panos!
>
> +1 (binding)
>
> Best,
> Piotrek
>
> śr., 19 kwi 2023 o 13:49 Piotr Nowojski
> napisał(a)
Hi Panos,
It seems that most recent discussions (e.g. changing the semantics of the
config option) are not reflected in the FLIP. Can you please double-check
that this is the correct version?
Best,
D.
On Mon, Apr 17, 2023 at 9:24 AM Panagiotis Garefalakis
wrote:
> Hello everyone,
>
> I want
cc dev@f.a.o
On Sun, Apr 16, 2023 at 11:42 AM David Morávek wrote:
> Hi Alexey,
>
> I'm a bit skeptical because, looking at the project, I see a couple of red
> flags:
>
> - The project is inactive. The last release and commit are both from the
> last May.
> - The proj
Does anyone know what happened to the diagrams that used to be in
FLIP-24: SQL Client? The last time I looked at this FLIP -- a few
weeks ago -- there were architecture diagrams for Gateway Mode and
Embedded Mode, but now those images are missing.
David
(testHarness.numEventTimeTimers(), is(1));
// should cause the fire timer to fire
testHarness.processWatermark(new Watermark(20L));
assertThat(testHarness.numEventTimeTimers(), is(0));
// verify the results
assertThat(testHarness.getOutput(), containsInExactlyThisOrder(6L));
Best,
David
On Wed, Mar 22, 2023
t; >>
> > > >> - independent execution vs ordered execution: I prefer the listeners
> > > being
> > > >> processed independently from each other because it adds less
> > complexity
> > > >> code-wise. The use case Piotr described (where yo
more quickly.
> >
> > Regards,
> > Dian
> >
> >
> >
> > On Tue, Mar 21, 2023 at 4:36 PM Gen Luo wrote:
> >
> > > Hi Panagiotis,
> > >
> > > Thanks for the proposal.
> > >
> > > It's useful to enrich the i
3 AM Panagiotis Garefalakis
wrote:
> Hey David, Shammon,
>
> Thanks for the valuable comments!
> I am glad you find this proposal useful, some thoughts:
>
> @Shammon
>
> 1. How about adding more job information in FailureListenerContext? For
> > example, job vertext, sub
Hi Panagiotis,
This is an excellent proposal and something everyone trying to provide
"Flink as a service" needs to solve at some point. I have a couple of
questions:
If I understand the proposal correctly, this is just about adding tags to
the Throwable by running a tuple of (Throwable,
> Although YARN serves as the platform for Flink, does YARN also operate on
K8s?
YARN is an alternative to k8s and Flink should make no assumptions about
how it's deployed, even though some companies might deploy it as an overlay
RM on top of k8s (I doubt that, but I guess they might do it for
+1 (binding)
Best,
D.
On Fri, Mar 10, 2023 at 4:49 AM Yuxin Tan wrote:
> Thanks, Weihua!
> +1 (non-binding)
>
> Best,
> Yuxin
>
>
> weijie guo 于2023年3月10日周五 11:29写道：
>
> > +1 (binding)
> >
> > Best regards,
> >
> > Weijie
> >
> >
> > Shammon FY 于2023年3月10日周五 11:02写道：
> >
> > > Thanks weihua,
David Anderson created FLINK-31388:
--
Summary: restart from savepoint fails with "userVisibleTail should
not be larger than offset. This is a bug."
Key: FLINK-31388
URL: https://issues.apache.org/j
David Anderson created FLINK-31361:
--
Summary: job created by sql-client can't authenticate to kafka,
can't find org.apache.kafka.common.security.plain.PlainLoginModule
Key: FLINK-31361
URL: https
Hi Surendra,
Since you're mentioning docker, I assume you're deploying your application
to k8s. Is that correct?
For handcrafted Kubernetes deployments, you can simply download the jar
into the user lib folder in an init container [1]. You can usually reuse
existing docker images to download the
I'm happy to announce that we have unanimously approved this FLIP.
There are 8 approving votes, 3 of which are binding:
* John Roesler
* Konstantin Knauf (binding)
* Zhanghao Chen
* ConradJam
* Feng Xiangyu
* Gyula Fóra (binding)
* Roman Khachatryan (binding)
* Shammon FY
There are no
Thanks, everyone, I'm closing this vote now. I'll follow up with the result
in a separate email.
On Wed, Mar 1, 2023 at 10:01 AM Shammon FY wrote:
> +1 (non-binding)
>
> Best,
> Shammon
>
>
> On Wed, Mar 1, 2023 at 4:51 PM Roman Khachatryan wrote:
>
> > +1
Hi Everyone,
I want to start the vote on FLIP-291: Externalized Declarative Resource
Management [1]. The FLIP was discussed in this thread [2].
The goal of the FLIP is to enable external declaration of the resource
requirements of a running job.
The vote will last for at least 72 hours (Friday,
gt; environments with multiple jobs: Scheduler will then have an option to stop
> the less suitable job.
> In 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
state.
We're still planning to dig deeper in this direction with other efforts,
but this is already good enough and should allow us to move the FLIP
forward.
WDYT? Unless there are any objectives against the above, I'd like to
proceed to a vote.
Best,
D.
On Thu, Feb 23, 2023 at 5:39 PM David
Hi Weihua, I still need to dig into the details, but the overall sentiment
of this change sounds reasonable.
Best,
D.
On Mon, Feb 27, 2023 at 2:26 PM Zhanghao Chen
wrote:
> Thanks for driving this topic. I think this FLIP could help clean up the
> codebase to make it easier to maintain. +1 on
I think this makes sense, +1 from my side; as I wrote on the ticket, I'm
not aware of any other usages apart from the kinesis connector, and we
already have more feature complete API that can replace the functionality
there.
Best,
D.
On Mon, Feb 27, 2023 at 2:44 PM Zhanghao Chen
wrote:
> Hi
Congratulations Anton, well deserved!
Best,
d.
On Wed, Feb 22, 2023 at 5:01 AM Jane Chan wrote:
> Congratulations, Anton!
>
> Best regards,
> Jane
>
> On Wed, Feb 22, 2023 at 11:22 AM Yun Tang wrote:
>
> > Congratulations, Anton!
> >
> > Best
> > Yun Tang
> >
at 12:24 AM John Roesler wrote:
> Thanks for the FLIP, David!
>
> I just had one small question. IIUC, the REST API PUT request will go
> through the new DispatcherGateway method to be handled. Then, after
> validation, the dispatcher would call the new JobMasterGateway method to
&g
wouldn't achieve what we had in mind,
> > i.e. sticking to the old resource requirements until enough slots are
> > available to fulfil the new resource requirements. So this may not be
> > 100% what we need but it could be extended to do what we want.
> >
> > -Max
&
D.
On Fri, Feb 10, 2023 at 11:21 AM feng xiangyu wrote:
> Hi David,
>
> Thanks for creating this flip. I think this work it is very useful,
> especially in autoscaling scenario. I would like to share some questions
> from my view.
>
> 1, Is it possible for this REST API to de
ys one, and for the upper bound,
it's either parallelism (if defined) or the maxParallelism of the vertex in
JobGraph. This question might be another signal for making the defaults
explicit (see the answer to Shammon's question above).
Thanks, everyone, for your initial thoughts!
Best,
D.
On Tue, Feb 7
+1
I don't have anything substantive to add, but I want to express how pleased
I am to see this conversation happening.
David
On Thu, Feb 2, 2023 at 5:09 AM Martijn Visser
wrote:
> Hi all,
>
> +1 for the overall proposal. My feedback matches with what Matthias
> has already prov
Thanks for the detailed FLIP, Matthias; this will simplify the HA code-base
significantly.
+1 (binding)
Best,
D.
On Tue, Jan 31, 2023 at 5:22 AM Yang Wang wrote:
> +1 (Binding)
>
> Best,
> Yang
>
> ConradJam 于2023年1月31日周二 12:09写道：
>
> > +1 non-binding
> >
> > Matthias Pohl 于2023年1月25日周三
Hi everyone,
This FLIP [1] introduces a new REST API for declaring resource requirements
for the Adaptive Scheduler. There seems to be a clear need for this API
based on the discussion on the "Reworking the Rescale API" [2] thread.
Before we get started, this work is heavily based on the
, it's already prepared and we should be able to
publish it until Friday.
Best,
D.
On Wed, Feb 1, 2023 at 9:56 AM Gyula Fóra wrote:
> Chesnay, David:
>
> Thank you guys for the extra information. We were clearly missing some
> context here around the scheduler related efforts
eant as a better version of the default scheduler for
> streaming jobs.
>
> On 26/01/2023 19:06, David Morávek wrote:
> > Hi Gyula,
> >
> >
> >> can you please explain why the AdaptiveScheduler is not the default
> >> scheduler?
> >
> > T
Hi Gyula,
> can you please explain why the AdaptiveScheduler is not the default
> scheduler?
There are still some smaller bits missing. As far as I know, the missing
parts are:
1) Local recovery (reusing the already downloaded state files after restart
/ rescale)
2) Support for fine-grained
David Christle created FLINK-30751:
--
Summary: Remove references to disableDataSync in RocksDB
documentation
Key: FLINK-30751
URL: https://issues.apache.org/jira/browse/FLINK-30751
Project: Flink
David Anderson created FLINK-30563:
--
Summary: Update training exercises to use Flink 1.16
Key: FLINK-30563
URL: https://issues.apache.org/jira/browse/FLINK-30563
Project: Flink
Issue Type
I'm also in favor of extending the feature freeze to Jan 31st.
David
On Thu, Dec 29, 2022 at 9:01 AM Leonard Xu wrote:
> Thanks Qingsheng for the proposal, the pandemic has really impacted
> development schedules.
>
> Jan 31st makes sense to me.
>
>
> Best,
> Leonard
>
>
David Hrbacek created FLINK-30475:
-
Summary: Improved speed of RocksDBMapState clear() using
rocksDB.deleteRange
Key: FLINK-30475
URL: https://issues.apache.org/jira/browse/FLINK-30475
Project: Flink
+1 (binding)
On Fri, Dec 16, 2022 at 12:22 PM Martijn Visser
wrote:
> Hi all,
>
> I'm bumping this old vote thread once more.
>
> If we want to add Java 17 support at some point, we will need to update
> our Scala 2.12 version (see
> https://issues.apache.org/jira/browse/FLINK-25000). As
David Anderson created FLINK-30442:
--
Summary: Update table walkthrough playground for 1.12
Key: FLINK-30442
URL: https://issues.apache.org/jira/browse/FLINK-30442
Project: Flink
Issue Type
101 - 200 of 588 matches
Mail list logo
