; > > This option requires a SNAPSHOT dependency between Flink
> > > repositories, but it is pretty much how things work at the
> > moment.
> > >
> > > b) Synced releases
> > >
> > > Similar to a), except that each repository gets
in the blink planner, and
> > this
> > > > > should be applicable for all modules. However, I presume
> > > there's
> > > > > a reason why we disabled JVM reuse (information on this
> would
> > > be
> > > > &g
to always have a static method to create
> the
> >> builder with static method names that end in builder.
> >>
> >> 2. Setting properties on the builder:
> >>
> >> a) withSomething(...)
> >> b) setSomething(...)
> >> c) other
> >>
> &
mats use fs.getDefaultBlockSize()
> >> to set this value by default, so maybe the root issue is S3 somehow
> >> reporting different values.
> >>
> >> But it does feel a bit odd that we’re relying on this default setting,
> >> versus it being recorded in the file d
t;2217232...@qq.com> 于2019年8月30日周五 下午10:23写道：
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> I thinks it's better to increase the default value. +1
>>>>>>>
>>>>&g
>> >>>>>>>> Past approaches
> >> >>>>>>>>
> >> >>>>>>>> Over the years we have done rather few things to improve this
> >> >>>>>>>> situation (hence our current predicament).
> >> >>>>>>>>
> >
oin and it's performance in
another thread in the user list u...@flink.apache.org ?
Best,
Arvid
On Tue, Sep 3, 2019 at 8:17 PM Ken Krugler
wrote:
> Hi Arvid,
>
> Thanks for following up…
>
> On Sep 2, 2019, at 3:09 AM, Arvid Heise wrote:
>
> Hi Ken,
>
>
the schema on failure.
>
> This would be a very simple addition and could be added as optional methods
> to the interface to not break any schemas that are implemented as lambdas.
>
> What do you think?
>
> Gyula
>
--
Arvid Heise | Senior Software Engineer
<https://w
Couldn't we treat a missing option as legacy, but set the new scheduler as
the default value in all newly shipped flink-conf.yaml?
In this way, old users get the old behavior (either implicitly or
explicitly) unless they explicitly upgrade.
New users benefit from the new scheduler.
On Wed, Feb 5,
Let me be a troll, but couldn't we just disable push to master for
committers?
That would make smaller backports harder, but it would also eliminate
unreviewed commits. And we wouldn't need to draw a line between minor for
direct push and bigger changes that need review.
On Wed, Feb 19, 2020 at 1
Fair benchmarks are notoriously difficult to setup.
Usually, it's easy to find a workload where one system shines and as its
vendor you report that. Then, the competitor benchmarks a different use
case where his system outperforms ours. In the end, customers are more
confused than before.
You sho
, so from my understanding, Flink uses AWS SDK behind the scenes
> same as spark.
>
> On Wed, Feb 26, 2020 at 8:49 AM Arvid Heise wrote:
>
>> Fair benchmarks are notoriously difficult to setup.
>>
>> Usually, it's easy to find a workload where one system shines
Dear devs,
development speed of Flink has steadily increased. Lots of new concepts are
introduced and technical debt removed. However, it's hard to keep track of
these things if you are not directly involved. Especially for new
contributors, it's often not easy to know what the best practices are
Hi Sivaprasanna,
we actually want to remove Hadoop from all core modules, so we could not
place it in some very common place like flink-core.
But I think the module flink-hadoop-fs could be a fitting place.
On Tue, Mar 3, 2020 at 11:25 AM Sivaprasanna
wrote:
> Hi
>
> The flink-sequence-file mo
idea, but I also second Seth's comment to separate this
> > in
> > > a
> > > > > > clear
> > > > > > > > way. It's easy to confuse new / potential users.
> > > > > > > >
> > > > &
quest topics? :)
> >> )
> >>>>>>>
> >>>>>>> We could start very low key by using our wiki's blog feature:
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >
t; maybe we can use markdown & GitHub to make the submission easy
> to
> > > > > review
> > > > > > > I have set up a similar blog for Flink-china blog
> > > before(deprecated),
> > > > > > glad
> > > > > > > t
Dear devs,
we conducted some POCs and updated the FLIP accordingly [1].
Key changes:
- POC showed that it is viable to spill only on checkpoint (in contrast to
spilling continuously to avoid overload of external systems)
- Greatly revised/refined recovery and rescaling
- Sketched the required com
>> Thanks a for this proposal.
> > > >>>
> > > >>> As a new contributor to Flink, it would be very helpful to have
> such
> > > >> blogs
> > > >>> for us to understand the future of Flink and get involved
> > > >&
Hi LakeShen,
you can change the port with
conf.setInteger(RestOptions.PORT, 8082);
or if want to be on the safe side specify a range
conf.setString(RestOptions.BIND_PORT, "8081-8099");
On Mon, Mar 9, 2020 at 10:47 AM LakeShen wrote:
> Hi community,
>now I am moving the flink job to
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/F
lism to resolve a prolonged/permanent backpressure condition?
>
> Thanks,
> Thomas
>
>
> On Tue, Mar 10, 2020 at 6:33 AM Arvid Heise wrote:
>
> > Hi all,
> >
> > I would like to start the vote for FLIP-76 [1], which is discussed and
> > reached a consensus
on wrote:
> > >
> > > +1 I like where this is headed.
> > >
> > > One question: during restore, it could happen that a new task manager
> is
> > > configured with fewer or smaller buffers than was previously the case.
> > How
> > > will this be
wrote:
> +1 (binding)
>
> The updated FLIP doc LGTM. Thanks for addressing the comments Arvid and
> Roman.
>
> Best Regards,
> Yu
>
>
> On Fri, 13 Mar 2020 at 03:48, Arvid Heise wrote:
>
> > I added a roadmap section to the FLIP as suggested by Yu and Roman.
&g
Thank you Robert! (also thanks for incorporating my feedback so swiftly)
On Mon, Mar 23, 2020 at 8:54 PM Seth Wiesman wrote:
> Very interesting! No questions but thank you for taking the initiative to
> put out the first dev blog.
>
> Seth
>
> > On Mar 23, 2020, at 5:14 AM, Robert Metzger wrote
Hi Krzysztof,
from my past experience as data engineer, I can safely say that users often
underestimate the optimization potential and techniques of the used
systems. I implemented a similar thing in the past, where I parsed up to
500 rules reading from up to 10 data sources.
The basic idea was to
I saw that requirement but I'm not sure if you really need to modify the
query at runtime.
Unless you need reprocessing for newly added rules, I'd probably just
cancel with savepoint and restart the application with the new rules. Of
course, it depends on the rules themselves and how much state th
Congratulations!
On Wed, Apr 1, 2020 at 11:03 AM Dian Fu wrote:
> Congratulations to you all.
>
>
> > 在 2020年4月1日，下午5:00，Robert Metzger 写道：
> >
> > Welcome & congratulations to all of you!
> >
> >
> > On Wed, Apr 1, 2020 at 10:58 AM Jingsong Li
> wrote:
> >
> >> Congratulations! Konstantin, Da
. If there is interest in the Flink community for this
> capability, please contact us at d...@datasketches.apache.org or on our
> datasketches-dev Slack channel.
> Cheers,
> Lee.
>
--
Arvid Heise | Senior Java Developer
<https://www.ververica.com/>
Follow us @VervericaData
Hi Devs,
I would like to start the formal discussion about FLIP-76 [1], which
improves the checkpoint latency in systems under backpressure, where a
checkpoint can take hours to complete in the worst case. I recommend the
thread "checkpointing under backpressure" [2] to get a good idea why users
a
FYI, we published FLIP-76 to address the issue and discussion has been
opened in [1].
Looking forward to your feedback,
Arvid
[1] https://mail-archives.apache.org/mod_mbox/flink-dev/201909.mbox/browser
On Thu, Aug 15, 2019 at 9:43 AM Yun Gao
wrote:
> Hi,
> Very thanks for the great points
Sry incorrect link, please follow [1].
[1]
https://mail-archives.apache.org/mod_mbox/flink-dev/201909.mbox/%3CCAGZNd0FgVL0oDQJHpBwJ1Ha8QevsVG0FHixdet11tLhW2p-2hg%40mail.gmail.com%3E
On Wed, Oct 2, 2019 at 3:44 PM Arvid Heise wrote:
> FYI, we published FLIP-76 to address the issue
Hi guys,
I'm a bit torn. In general, +1 for making parameters effectively final.
The question is how to enforce it. We can make it explicit (like Aljoscha
said). All IDEs will show immediately warnings/errors for violations. It
would allow to softly migrate code.
Another option is to use a check
don’t remember having any issues
> with
> >>> the lack or presence of the `final` keyword.
> >>> - `final` is pretty much useless in most of the cases (it’s not `const`
> >>> and it works only for the primitive types).
> >>> - I don’t like the extra ov
Hi Dominik,
just to add to Dawids explanation: to have a proper schema evolution on
Avro data, it needs to know the schema with which it was written. For state
that means that we are storing the used schema once for all state records
in the state file, since they all belong to the same schema vers
+1 I had good experiences with Azure pipelines in the past.
On Thu, Dec 5, 2019 at 11:35 AM Aljoscha Krettek
wrote:
> +1
>
> Thanks for the effort! The tooling seems to be quite a bit nicer and I
> like that we can grow by adding more machines.
>
> Best,
> Aljoscha
>
> > On 5. Dec 2019, at 03:18
Hi Robert,
thank you very much for raising this issue and improving the build system.
For now, I'd like to stick to a lean solution (= option A).
While option B can greatly reduce build times, it also has the habit of
clogging up the build machines. Just some arbitrary numbers, but it
currently
A common approach is to add the connector jar as test dependencies and have
a smoke test that just starts the job with a temporary external system
spawned with docker. I usually use test containers [1]. Then you simply
need to execute the integration tests in your IDE and usually can even
debug non
non-binding +1
On Fri, Jan 10, 2020 at 9:11 AM Zhijiang
wrote:
> +1, it is really nice to have the N-Ary stream operator which is
> meaningful in some scenarios.
>
> best,
> Zhijiang
>
>
> --
> From:Jingsong Li
> Send Time:2020 Jan
+1 (non-binding)
On Thu, Jan 30, 2020 at 11:10 AM Fabian Hueske wrote:
> Hi Ismael,
>
> > Just one question, we will be able to still be featured as an official
> docker image in this case?
>
> Yes, that's the goal. We still want to publish official DockerHub images
> for every Flink release.
>
Dear Flinker,
can anyone try to build a Flink program against the 0.9-SNAPSHOT?
I receive the following maven error
[ERROR] error: error while loading , invalid CEN header (bad
signature)
[ERROR] error: scala.reflect.internal.MissingRequirementError: object
scala.runtime in compiler mirror not fo
I mean the snapshots obtained from
https://repository.apache.org/content/repositories/snapshots/
On Wed, Feb 18, 2015 at 1:26 PM, Robert Metzger wrote:
> Hi,
>
> do you mean the maven snapshot repository or the nightly build?
>
> On Wed, Feb 18, 2015 at 1:14 PM, Arvid Heise
>
d, Feb 18, 2015 at 1:31 PM, Arvid Heise wrote:
> I mean the snapshots obtained from
> https://repository.apache.org/content/repositories/snapshots/
>
> On Wed, Feb 18, 2015 at 1:26 PM, Robert Metzger
> wrote:
>
>> Hi,
>>
>> do you mean the maven snapshot reposi
ver,
> we're in the process of hopefully getting rid of it there with our work
> on sources and sinks. Before we fully remove it, we should of course
> signal this to users by deprecating it.
>
> What do you think?
>
> Best,
> Aljoscha
>
--
Arvid Heise | Senior Java
on
> dev@
> > > >> list,
> > > >> supporting users and giving talks at conferences.
> > > >>
> > > >> Please join me in congratulating Niels for becoming a Flink
> committer!
> > > >>
> > > >> Best,
> &
Jul. 2018).
> >
> > Please join me in congratulating Yun for becoming a Flink committer!
> >
> > Cheers,
> > Yu
> >
>
--
Arvid Heise | Senior Java Developer
<https://www.ververica.com/>
Follow us @VervericaData
--
Join Flink Forward <https://f
s the
> > original
> > > > > author
> > > > > > of it before it was contributed to Flink.
> > > > > > Ever since StateFun was contributed to Flink, he has consistently
> > > > > > maintained the project and supported users in t
gt; > > > > Paul Lam
> > > > > > > >
> > > > > > > > > 2020年9月15日 15:29，Jingsong Li 写道：
> > > > > > > > >
> > > > > > > > > Congratulations Arvid !
> > > > > > > > >
> &g
Zhu has joined the Flink PMC!
> >
> > Zhu is helping the community a lot with creating and validating releases,
> > contributing to FLIP discussions and good code contributions to the
> > scheduler and related components.
> >
> > Congratulations and welcome Zhu Zhu!
>
gt; > already "well" formatted not much would change.
> >
> > - In the short-term it will be harder to apply changes both to master
> > and one of the release-x branches because formatting will be
> > different. I think this is not too hard though because Spotless can
r option (a separate discussion that I'll gladly skip).
[1]
https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame
On Tue, Oct 6, 2020 at 5:38 PM Arvid Heise wrote:
> I'm also +1 for automatically enforceable code style.
>
> I also would just go over it as Chesnay sa
b0312a290a1d4a339c1%40%3Cuser.flink.apache.org%3E
>> [3]
>> https://lists.apache.org/thread.html/rad4adeec838093b8b56ae9e2ea6a937a4b1882b53045a12acb7e61ea%40%3Cuser.flink.apache.org%3E
>> [4]
>> https://lists.apache.org/thread.html/4cf28a9fa3732dfdd9e673da6233c5288ca80b20d58ce
ount of records after failover due to no periodic checkpoints are taken
> after the bounded sources finished.
>
> Therefore, we propose to also support checkpoints after some tasks finished.
> Your Could find more details in FLIP-147[6].
> Best,
> Yun
>
> [1]
> http
se case.
> >
> > Ah yes, I see FLIP-147 as a more general replacement for FLIP-46. Thanks
> > for the reminder, we should close FLIP-46 now with an explanatory
> > message to avoid confusion.
>
--
Arvid Heise | Senior Java Developer
<https://www.ververica.com/>
Foll
to be created at a process(JM/TM) level?
>
> Can someone please help answer the above questions and help me understand
> the flink-guarantees better. Any help would be greatly appreciated.
>
> Thanks.
>
--
Arvid Heise | Senior Java Developer
<https://www.ververica.com/>
Fol
inging this up now: I'm spending
> > quite a
> > > lot of time trying to figure out really hard to debug issues with our
> > bash
> > > testing infra.
> > > Also, it is very difficult to introduce something generic for all tests
> > > (such as
ZE
> Nov 21, 2020 10:39:06 PM org.apache.tika.utils.XMLReaderUtils
> acquireSAXParser
> WARNING: Contention waiting for a SAXParser. Consider increasing the
> XMLReaderUtils.POOL_SIZE
> Nov 21, 2020 10:39:07 PM org.apache.tika.utils.XMLReaderUtils
> acquireSAXParser
> WARNING:
y.
4. Remove vintage runner, once most tests are migrated by doing a final
push for lesser used modules.
Let me know what you think and I'm happy to answer all questions.
--
Arvid Heise | Senior Java Developer
<https://www.ververica.com/>
Follow us @VervericaData
--
Join Flink Forwa
m wary of this
> > migration dragging on for too long.
> >
> > On 11/27/2020 3:29 PM, Arvid Heise wrote:
> >> Dear devs,
> >>
> >> I'd like to start a discussion to migrate to a higher JUnit version.
> >>
> >> The main motivati
Just wanted to express my support for the idea. I did miss certain
> features of JUnit 5 already, an important one being much better support
> for parameterized tests.
>
> Best,
>
> Dawid
>
> On 30/11/2020 13:50, Arvid Heise wrote:
> > Hi Chesnay,
> >
> >
blob/c2972b6e336cc3b3a6cbd22c69a6710dab5246e6/flink-container/src/main/java/org/apache/flink/container/entrypoint/StandaloneApplicationClusterConfigurationParserFactory.java#L56
> > >
> > [3]
> >
> https://github.com/apache/flink/blob/c2972b6e336cc3b3a6cbd22c69a6710dab5246e6
t;>> community feel about making the documentation "blink only"?
> > >>>
> > >>> We would update the documentation to assume users are always using
> the
> > >>> Blink planner. As the legacy planner still exists we would create a
> &
>>>> not
> > >>>>>> supported by Github (yet?) [2] as mentioned in [1].
> > >>>>>>
> > >>>>>> Considering all that I prefer applying the code style in one go. I
> > >>>> have no
> > >&g
iple source tasks (legacy and new source) and multiple non-source tasks
> > (one-input, two-input, multiple-input), it would cause the cases that
> > multiple subclasses share the same implementation and cause code
> > repetition. Currently the PoC introduces a new level of
--
> From:Aljoscha Krettek
> Send Time:2021 Jan. 5 (Tue.) 22:34
> To:dev
> Cc:Yun Gao
> Subject:Re: [DISCUSS] FLIP-147: Support Checkpoints After Tasks Finished
>
> On 2021/01/05 10:16, Arvid Heise wrote:
> >1. I'd think that this is an orthogonal issue, wh
ractical purposes on checkpoint barrier alignment, EndOfPartitions
should make the channel being excluded from alignment (the respective
channel has implicitly received all future barriers).
On Wed, Jan 6, 2021 at 10:46 AM Aljoscha Krettek
wrote:
> On 2021/01/05 17:27, Arvid Heise wrote:
>
ed.
>>
>> 1) Who from the Flink community will mentor this effort and could take
>> responsibility for it?
>>
>
> We had a conversation with Stephen and Arvid about this. I think Arvid
> Heise was willing to mentor this effort.
>
>
>> 2) How can Pulsar be
ught this was
the initial goal of the whole FLIP to being with). However, that would
require subtasks to stay alive until they receive checkpiontCompleted
callback (which is currently also not guaranteed)...
On Wed, Jan 6, 2021 at 12:17 PM Aljoscha Krettek
wrote:
> On 2021/01/06 11:30, A
re-trigger the
> following tasks.
> Of couse this is one possible implementation and we might have other
> solutions to this problem. Do you think the process would still have some
> problems ?
>
> > However, that would
> > require subtasks to stay alive until they receive checkpiontCompleted
the live task.
Clear downside (assuming feasibility) is that we have two code paths that
would deal with barriers. We would also need to keep more information in
the TM but again at some point the complete subtask fitted.
On Wed, Jan 6, 2021 at 4:39 PM Aljoscha Krettek wrote:
> On 2021/01/06
nalized()` that the
> framework can call after each checkpoint (and potentially at other
> points)
>
> This way we would decouple that logic from things that don't actually
> need it. What do you think?
>
> Best,
> Aljoscha
>
--
Arvid Heise | Senior Java Deve
y)
>
> Any advice is greatly appreciated
>
>
> All the best,
>
> Carsten
>
>
>
--
Arvid Heise | Senior Java Developer
<https://www.ververica.com/>
Follow us @VervericaData
--
Join Flink Forward <https://flink-forward.org/> - The Apache Flink
Conference
S
://dist.apache.org/repos/dist/dev/flink/flink-1.12.1-rc2
> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> > [4]
> https://repository.apache.org/content/repositories/orgapacheflink-1411
> > [5] https://github.com/apache/flink/releases/tag/release-1.12.1-rc2
&g
An alternative way that may not be applicable in your case:
For Sopremo, all types implemented a common interface. When a package is
loaded, the Sopremo package manager scans the jar and looks for classes
implementing the interfaces (quite fast, because not the entire class must
be loaded). All ty
hat it's Scala :)
> >
> > 2015-01-29 16:24 GMT+01:00 Alexander Alexandrov <
> > alexander.s.alexand...@gmail.com>:
> >
> >> have you tried declaring your UDF classes (e.g. TotalRankDistribution)
> as
> >> static?
> >>
> >> 201
Nevermind, I'm going to build it myself and try your patch.
On Thu, Jan 29, 2015 at 4:39 PM, Arvid Heise wrote:
> No I'm using the maven builds, I could try a nightly if you like.
>
> On Thu, Jan 29, 2015 at 4:34 PM, Aljoscha Krettek
> wrote:
>
>> Hi Arv
Quickfix did not help :/
Any other idea?
On Thu, Jan 29, 2015 at 4:45 PM, Arvid Heise wrote:
> Nevermind, I'm going to build it myself and try your patch.
>
> On Thu, Jan 29, 2015 at 4:39 PM, Arvid Heise
> wrote:
>
>> No I'm using the maven builds, I could try
A quick and dirty hack revealed that the loader is null at the time of
failure with and without your patch.
On Thu, Jan 29, 2015 at 5:05 PM, Arvid Heise wrote:
> Quickfix did not help :/
> Any other idea?
>
> On Thu, Jan 29, 2015 at 4:45 PM, Arvid Heise
> wrote:
>
>>
Sorry building the 0.9 branch took longer than expected. I will follow that
up on Monday.
Alternatively I would be grateful for a 0.8.0 patch ;)
Best,
Arvid
On Fri, Jan 30, 2015 at 5:09 PM, Aljoscha Krettek
wrote:
> Hi Arvid,
> I have a fix that I hope fixes your problem:
> https://github.com
OK, patch indeed worked for my workflow. Thank you very much.
Any idea when this patch will be in a non-snapshot?
Best,
Arvid
On Fri, Jan 30, 2015 at 6:04 PM, Arvid Heise wrote:
> Sorry building the 0.9 branch took longer than expected. I will follow
> that up on Monday.
>
> Alt
Congratulations and well deserved!
On Mon, Mar 14, 2022 at 9:30 AM Matthias Pohl wrote:
> Congratulations, Yuan.
>
> On Mon, Mar 14, 2022 at 9:25 AM Shuo Cheng wrote:
>
> > Congratulations, Yuan!
> >
> > On Mon, Mar 14, 2022 at 4:22 PM Anton Kalashnikov
> > wrote:
> >
> > > Congratulations, Yu
Gratz!
On Mon, Mar 14, 2022 at 9:24 AM Anton Kalashnikov
wrote:
> Congratulations, David!
>
> --
>
> Best regards,
> Anton Kalashnikov
>
> 14.03.2022 09:18, Matthias Pohl пишет:
> > Congratulations, David!
>
>
watermark. I
> thought the problem is that we may have late data for this slow
>
> partition.
>
> I have another question about the restart. Say split alignment is
> triggered. checkpoint is completed. job failed and restored from the last
> checkpoint. because alignment deci
Hi Qingsheng,
Thanks for driving this; the inconsistency was not satisfying for me.
I second Alexander's idea though but could also live with an easier
solution as the first step: Instead of making caching an implementation
detail of TableFunction X, rather devise a caching layer around X. So the
+1 to deprecate Java 8, so we can hopefully incorporate the module concept
in Flink.
On Thu, Nov 25, 2021 at 9:49 AM Chesnay Schepler wrote:
> Users can already use APIs from Java 8/11.
>
> On 25/11/2021 09:35, Francesco Guardiani wrote:
> > +1 with what both Ingo and Matthias sad, personally, I
https://github.com/pravega/flink-connectors/releases/tag/v0.10.1
> [4] https://search.maven.org/search?q=pravega-connectors-flink
>
> Best Regards,
> Brian
>
>
> Internal Use - Confidential
>
> -Original Message-
> From: Arvid Heise
> Sent: Friday, November
>
> > One way to avoid write-read-merge is by wrapping SinkWriter with
> > another one, which would buffer input elements in a temporary storage
> > (e.g. local file) until a threshold is reached; after that, it would
> > invoke the original SinkWriter. And if a checkpoint barrier comes in
> > earl
+1 (binding)
On Mon, Dec 6, 2021 at 5:43 PM Timo Walther wrote:
> +1 (binding)
>
> Thanks,
> Timo
>
> On 06.12.21 17:28, David Morávek wrote:
> > +1 (non-binding)
> >
> > On Mon, Dec 6, 2021 at 4:55 PM Ingo Bürk wrote:
> >
> >> +1 (non-binding)
> >>
> >>
> >> Ingo
> >>
> >> On Mon, Dec 6, 2021
Could someone please help me understand the implications of the upgrade?
As far as I understood this upgrade would only affect users that have a
zookeeper shared across multiple services, some of which require ZK 3.4-? A
workaround for those users would be to run two ZKs with different versions,
e
hat utilities and infrastructure code do you intend to share? Using git
> > submodules can definitely be one option to share code. However, it might
> > also be ok to depend on flink-connector-common artifacts which could make
> > things easier. Where I am unsure is whether git submodu
> > > >> consisting of composable interfaces that do not offer the
> > > >>
> > > >> GlobalCommitter anymore. We will implement a utility to extend a
> Sink
> > > >>
> > > >> with post topology that mimics the behavior of t
t do it without breaking the Sink
> > > >>
> > > >> interface since the GlobalCommittables are part of the parameterized
> > > >>
> > > >> Sink interface. Thus, we propose building a new Sink V2 interface
> > > >>
> > > >> consisting
s well, so the FLIP is not
making anything worse.
On Thu, Dec 16, 2021 at 1:53 PM Arvid Heise wrote:
> Hi Yun,
>
> the basic idea is to use different regions for the different stages.
>
> So you have your stages:
> Stage 1: -> pre-writer topology -> writer -> co
+1 (binding).
Thanks for driving!
On Tue, Jan 4, 2022 at 10:31 AM Yun Gao
wrote:
> +1 (binding).
>
> Very thanks for proposing the FLIP!
>
> Best,
> Yun
>
>
> --
> From:Martijn Visser
> Send Time:2022 Jan. 4 (Tue.) 17:22
> To:dev
gt; > > > > > > On Wed, Jan 20, 2021 at 1:36 PM tison
> > > wrote:
> > > > > > >
> > > > > > > > Congrats Guowei!
> > > > > > > >
> > > > > > > > Best,
> > > > > > > >
+1 (binding)
Best,
Arvid
On Wed, Jan 20, 2021 at 12:13 PM Aljoscha Krettek
wrote:
> +1 (binding)
>
> Best,
> Aljoscha
>
> On 2021/01/15 22:55, Yun Gao wrote:
> >
> >Hi all,
> >
> >I would like to start the vote for FLIP-147[1], which propose to support
> checkpoints after
> >tasks finished and
igrate+Flink+Documentation+from+Jekyll+to+Hugo
> >[2]
> >
> https://lists.apache.org/thread.html/r88152bf178381c5e3bc2d7b3554cea3d61cff9ac0edb713dc518d9c7%40%3Cdev.flink.apache.org%3E
>
--
Arvid Heise | Senior Java Developer
<https://www.ververica.com/>
Follow us @VervericaData
--
Dear users,
Unfortunately, the bug in the unaligned checkpoint that we fixed in 1.12.1
still occurs under certain circumstances, such that we recommend to not use
unaligned checkpoints in production until 1.12.2. While the normal
processing is not affected by this bug, a recovery with corrupted
ch
lp prepare the warning messages?
>
> Thank you~
>
> Xintong Song
>
>
> [1]
>
> https://github.com/apache/flink/blob/master/docs/release-notes/flink-1.12.md
>
> [2]
>
> https://github.com/apache/flink-web/blob/asf-site/_posts/2021-01-19-release-1.12.1.md
>
&
Hi Till,
I completely agree with you.
Best,
Arvid
On Fri, Jan 22, 2021 at 1:46 PM Till Rohrmann wrote:
> Thanks for the update Arvid. This fix warrants a quick 1.12.2 release imo.
>
> Cheers,
> Till
>
> On Fri, Jan 22, 2021 at 1:42 PM Arvid Heise wrote:
>
> > Hi X
1 - 100 of 386 matches
Mail list logo
