I mean the snapshots obtained from
https://repository.apache.org/content/repositories/snapshots/
On Wed, Feb 18, 2015 at 1:26 PM, Robert Metzger rmetz...@apache.org wrote:
Hi,
do you mean the maven snapshot repository or the nightly build?
On Wed, Feb 18, 2015 at 1:14 PM, Arvid Heise
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 arvid.he...@gmail.com wrote:
Quickfix did not help :/
Any other idea?
On Thu, Jan 29, 2015 at 4:45 PM, Arvid Heise arvid.he...@gmail.com
:)
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?
2015-01-29 16:14 GMT+01:00 Arvid Heise arvid.he...@gmail.com:
Hi Flinker,
I'm currently desparetely trying
Quickfix did not help :/
Any other idea?
On Thu, Jan 29, 2015 at 4:45 PM, Arvid Heise arvid.he...@gmail.com wrote:
Nevermind, I'm going to build it myself and try your patch.
On Thu, Jan 29, 2015 at 4:39 PM, Arvid Heise arvid.he...@gmail.com
wrote:
No I'm using the maven builds, I could
T 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 their own
> source
> > > relea
> > > a reason why we disabled JVM reuse (information on this
> would
> > > be
> > > > > appreciated)
> > > > > 2. Custom differential build scripts
> > > > > * Setup custom scripts for determining which modules
>> builder with static method names that end in builder.
> >>
> >> 2. Setting properties on the builder:
> >>
> >> a) withSomething(...)
> >> b) setSomething(...)
> >> c) other
> >>
> >> I don't really have a preference but either a o
写道：
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> I thinks it's better to increase the default value. +1
>>>>>>>
>>>>>>>
>>>>>>> Best.
>
t;>>>>>>>
> >> >>>>>>>> Over the years we have done rather few things to improve this
> >> >>>>>>>> situation (hence our current predicament).
> >> >>>>>>>>
> >> >>>>>>>> Beyond the sporadic speedup of some tests
gt;> 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 during the write phase.
> >>
>
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,
>
> that's indeed a very odd issue that y
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
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
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 is
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
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
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
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
gt; 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 overhead of doing something of very l
+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
, 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 sys
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
easy
> to
> > > > > review
> > > > > > > I have set up a similar blog for Flink-china blog
> > > before(deprecated),
> > > > > > glad
> > > > > > > to offer help if needed
> > > > > > >
> &g
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
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
;>>>>>
> >>>>>>> We could start very low key by using our wiki's blog feature:
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
to separate this
> > in
> > > a
> > > > > > clear
> > > > > > > > way. It's easy to confuse new / potential users.
> > > > > > > >
> > > > > > > > On Mon, Mar 2, 2020 at 8:15 PM
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
+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.
>
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
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
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-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
solve 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 in the dis
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
> > > >>>
> > > >>> 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
> > > >>>
> > > >>> B
> > > +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 handled?
> > >
&
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]
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
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
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,
nterest 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
--
Join Flink Forw
; >> > >
> >> > > Chesnay Schepler 于2020年4月29日周三 上午12:30写道：
> >> > >
> >> > > > Currently, processes started in the foreground (like in the case
> of
> >> > > > Docker) output all logging/stdout directly to the console, wit
; >>>>> Please check out the release blog post for an overview of the
> improvements for this bugfix release:
> >>>>> https://flink.apache.org/news/2020/05/12/release-1.10.1.html
> >>>>>
> >>>>> The full release notes are avai
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
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
issue reminded us that Kafka didn't
> >>>>> have an idempotent/fault-tolerant Producer before Kafka 0.11.0.
> >>>>> By now we have had the "modern" Kafka connector that roughly
> >>>>> follows new Kafka releases for a while
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 Developer
<https://www.ververica.co
).
> >
> > 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://flink-forwa
> 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 the mailing
gt; > > > > Paul Lam
> > > > > > > >
> > > > > > > > > 2020年9月15日 15:29，Jingsong Li 写道：
> > > > > > > > >
> > > > > > > > > Congratulations Arvid !
> > > > > > > > >
> &g
on
> dev@
> > > >> list,
> > > >> supporting users and giving talks at conferences.
> > > >>
> > > >> Please join me in congratulating Niels for becoming a Flink
> committer!
> > > >>
> > > >> Best,
> &
gt; >
> > 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/>
Follow us @Ver
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 said. While it makes s
; > - 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
> > automatically apply the style.
> >
> > In summary, we wou
u 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!
> >
user.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/4cf28a9fa3732dfdd9e673da6233c5288ca80b20d58cee130bf1c141%40%3Cuser.fli
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]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=1588
d has been giving numerous talks and trainings on
> > Flink.
> > > >On StackOverflow, he's among the most active helping Flink users to
> > solve
> > > >their problems (2nd in the all-time ranking, 1st in the last 30
> days). A
> > > >similar level of act
> > > > > >>>>
>> > > > > >>>>> Hi all,
>> > > > > >>>>>
>> > > > > >>>>> On behalf of the Flink PMC, I'm happy to announce that
>> Dian Fu
>> > is
>> > > > now
>&g
> > > > >Sruthi this Friday at Beam Summit [4]!
> > > > >
> > > > > They will be working to improve the Table API/SQL documentation
> over
> > a
> > > > > 3-month period, with the support of Aljoscha and Seth as mentors.
> &
;> be follow-up FLIPs that describe the necessary changes for the APIs that
>> we maintain.
>> --
>>
>> Please let us know if you have any concerns or comments. Also, please
>> keep discussion to this ML thread instead of commenting in the Wiki so
>>
se?
>
> Thanks,
> Thomas
>
>
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-76%3A+Unaligned+Checkpoints
>
> On Wed, Oct 2, 2019 at 12:11 PM Arvid Heise wrote:
>
>> Sry incorrect link, please follow [1].
>>
>> [
m the mailing list, or the release
> manager work.
>
> Congrats, Piotr!
>
> Best,
> Stephan
>
--
Arvid Heise | Senior Java Developer
<https://www.ververica.com/>
Follow us @VervericaData
--
Join Flink Forward <https://flink-forward.org/> - The Apache Flink
Confe
What happens when we have more slots than cores in following scenarios?
> 1) The transform is just changing of json format.
>
> 2) When the transformation is done by hitting another server (HTTP
> request)
>
> Thanks,
> Prasanna.
>
--
Arvid Heise | Senior Java Developer
<ht
y include this fix into
> the rc or do you think it is necessary to open a complete new one?
>
>
> [1] https://issues.apache.org/jira/browse/FLINK-18411 <
> https://issues.apache.org/jira/browse/FLINK-18411>
>
> Best,
> Fabian
--
Arvid Heise | Senior Java De
Thanks for helping us to improve this feature,
Arvid
--
Arvid Heise | Senior Java Developer
<https://www.ververica.com/>
Follow us @VervericaData
--
Join Flink Forward <https://flink-forward.org/> - The Apache Flink
Conference
Stream Processing | Event Driven | Real Time
--
Ve
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 Developer
<https://www
nce 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 Forward <https://flink-forward.org/&g
, but am 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 motivations are:
&
3a6cbd22c69a6710dab5246e6/flink-container/src/main/java/org/apache/flink/container/entrypoint/StandaloneApplicationClusterConfigurationParserFactory.java#L56
> > >
> > [3]
> >
> https://github.com/apache/flink/blob/c2972b6e336cc3b3a6cbd22c69a6710dab5246e6/flink-container/src
gt; 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
> >
IZE
> 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: Cont
st 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,
> >
> > The
gt;>> supported by Github (yet?) [2] as mentioned in [1].
> > >>>>>>
> > >>>>>> Considering all that I prefer applying the code style in one go. I
> > >>>> have no
> > >>>>>> strong opinion on what codestyl
s 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 a test-timeout,
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/>
Follow us @Ververi
wo-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 abstraction, namely
> > SourceStreamTasks and NonSourceStreamTasks, but what makes
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, which I'd solve separa
ght 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, Arvid Heise
t 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:
> >For your question: wil
;> 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 tested together with
s.
> 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
> > callback (which is
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 16:05, Arvid Heise wrote:
> &
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
s/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
> > [6] https://github.com/
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:
>
> > H
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
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
>
>
>
&
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
--
FLIP looks good to me. +1
On Wed, Feb 3, 2021 at 8:00 AM Piotr Nowojski wrote:
> I'm carrying over my +1 from the discussion thread.
>
> Piotrek
>
> śr., 3 lut 2021 o 05:55 Yuan Mei napisał(a):
>
> > As aforementioned in the discussion thread, +1 on this Flip vote.
> >
> > On Wed, Feb 3, 2021
> switch to Iceberg source
> > - once job caught up, switch back to Kafka source
> >
> > That can simplify operational aspects of manually switching.
> >
> >
> > On Mon, Jun 7, 2021 at 8:07 AM Arvid Heise wrote:
> >>
> >> Sorry for joining
Congratulations!
On Wed, Jun 16, 2021 at 12:05 PM 刘建刚 wrote:
> Congrats, Xintong!
>
> Best.
>
> Xintong Song 于2021年6月16日周三 下午5:51写道：
>
> > Thanks all for the support.
> > It's my honor to be part of the community and work with all of you great
> > people.
> >
> > Thank you~
> >
> > Xintong
Sorry for joining the party so late, but it's such an interesting FLIP with
a huge impact that I wanted to add my 2 cents. [1]
I'm mirroring some basic question from the PR review to this thread because
it's about the name:
We could rename the thing to ConcatenatedSource(s), SourceSequence, or
One more idea for the bot. Could we have a label to exclude certain tickets
from the life-cycle?
I'm thinking about long-term tickets such as improving DataStream to
eventually replace DataSet. We would collect ideas over the next couple of
weeks without any visible progress on the
; first-class way, optimize for correctness, etc. In this case, FLIP-167 is
> setting the stage for evolution in Pulsar.
>
> Thanks again Arvid for the great discussion.
>
>
>
>
>
> On Fri, Jun 4, 2021 at 2:06 PM Arvid Heise wrote:
>
> > At least one big motiv
d bound idleness *(if we would ever need to
> define/expose
> >> it)* should be an intermittent concept, like for example the existing in
> >> the Task/runtime input availability (StreamTaskInput#isAvailable).
> >> 3. I agree that neither `StreamStatus` nor `IDLE` is
I have not followed the complete discussion and can't comment on the
concepts. However, I have some ideas on the API changes:
1. If it's about adding additional life-cycle methods to UDFs, we should
add the flush/endOfInput to RichFunction as this is the current way to
define it. At this point, I
1 - 100 of 324 matches
Mail list logo
