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 a
Congrats! Well deserved.
On Wed, Feb 10, 2021 at 1:54 PM Yun Gao
wrote:
> Congratulations Roman!
>
> Best,
> Yun
>
>
> --Original Mail --
> Sender:Till Rohrmann
> Send Date:Wed Feb 10 20:53:21 2021
> Recipients:dev
> CC:Khachatryan Roman , Roman Khachatryan <
>
Dear devs,
I just merged FLINK-19520, which adds randomization to all tests that use
the MiniCluster(WithResource). The overall goal is to provide a faster and
better coverage for future changes in the network stack in particular in
conjunction with checkpointing.
We implemented it in a way to fu
Hi Piotr,
Thank you for raising your concern. Unfortunately, I do not have a better
idea than doing closing of operators intermittently with checkpoints (=
multiple last checkpoints).
However, two ideas on how to improve the overall user experience:
1. If an operator is not relying on notifyCheck
+1 from my side.
I would have probably never deprioritized blockers automatically. Just
because there is no activity doesn't mean that the nature of the ticket
changes (blockers are quite special). However, as blockers are by
definition resolved with urgency, I also cannot imagine a blocker going
+1 from my side.
Thanks for proposing!
On Fri, Mar 26, 2021 at 8:40 AM Robert Metzger wrote:
> +1 This is a very good improvement!
>
> Most likely we'll have to adjust the parameters a bit in the beginning,
> once we've seen it in practice, but this will help keep the Jira clean.
>
> On Wed, Ma
Hi Etienne,
In general, any small PR on this subject is very welcome. I don't think
that the community as a whole will invest much into FileInputFormat as the
whole DataSet API is phasing out.
Afaik SQL and Table API are only using InputFormat for the legacy
compatibility layer (e.g. when it come
Hi Dawid and Guowei,
I'd like to merge [FLINK-13550][rest][ui] Vertex Flame Graph [1]. We are
pretty much just waiting for AZP to turn green, it's separate from other
components, and it's a super useful feature for Flink users.
Best,
Arvid
[1] https://github.com/apache/flink/pull/15054
On Thu,
Hi Becket,
did you need to change anything to the source interface itself? Wouldn't it
be possible for users to simply use the 1.13 connector with their Flink
1.12 deployment?
I think the late-upgrade argument can be made for any feature, but I also
see that the Kafka connector is of high interes
In our nightly build, we run all modules against Java 11. [1]
The only reason we do not compile with Java 11 is that we want to
specifically test that our finally released jars that are compiled with
Java 8 also work with Java 11.
So there should be no reason to stick with Java 8; documentation is
+1
On Wed, Apr 14, 2021 at 11:21 AM Xintong Song wrote:
> +1
>
> Thank you~
>
> Xintong Song
>
>
>
> On Wed, Apr 14, 2021 at 4:58 PM Yangze Guo wrote:
>
> > +1
> >
> > Best,
> > Yangze Guo
> >
> > On Wed, Apr 14, 2021 at 4:56 PM Chesnay Schepler
> > wrote:
> > >
> > > +1
> > >
> > > On 4/14/20
Dear devs,
Since we just fixed a severe bug that causes the dataflow to halt under
specific circumstances [1], we would like to release a bugfix asap.
I would volunteer as the release manager and kick off the release process
on next Monday (April 19th).
What do you think?
Note that this time aro
+1 from my side. The transition between DataStream and Table should be as
smooth as possible.
On Wed, Apr 21, 2021 at 5:00 PM Timo Walther wrote:
> Thanks for the feedback.
>
> @Dawid: It should be merged by tomorrow. It has been reviewed already. I
> will just wait a few hours to let this discu
Congrats!
Best,
Arvid
On Thu, Apr 22, 2021 at 8:07 AM Xingbo Huang wrote:
> Congratulations Rui~!
>
> Best,
> Xingbo
>
> Xintong Song 于2021年4月22日周四 下午1:58写道：
>
> > Congrats, Rui~!
> >
> > Thank you~
> >
> > Xintong Song
> >
> >
> >
> > On Thu, Apr 22, 2021 at 11:52 AM Yun Gao
> > wrote:
> >
Hi everyone,
Please review and vote on the release candidate #1 for the version 1.12.3,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
The complete staging area is available for your review, which includes:
* JIRA release notes [1],
*
+1 from my side.
We should probably double-check if we really need 4h timeouts on test tasks
in AZP. It feels like 2h be enough.
On Mon, Apr 26, 2021 at 9:54 AM Dawid Wysakowicz
wrote:
> Hi devs!
>
> I wanted to bring up something that was discussed in a few independent
> groups of people in th
Just to add to Dong Lin's list of cons of allowing timeout:
- Any timeout value that you manually set is arbitrary. If it's set too
low, you get test instabilities. What too low means depends on numerous
factors, such as hardware and current utilization (especially I/O). If you
run in VMs and the V
gt; > > - Verified checksums and signatures
> > > - Reviewed the website PR
> > > - Built from sources
> > > - verified dependency version upgrades and updates in NOTICE files
> > > compared to 1.12.2
> > > - started cluster and run WordCount example in BAT
Dear devs,
I'm happy to announce that we have unanimously approved this release.
There are 3 approving votes, 3 of which are binding:
* Dian
* Dawid
* Robert
There are no disapproving votes.
Thanks everyone!
Your friendly release manager Arvid
On Wed, Apr 28, 2021 at 2:25 PM Arvid
Dear all,
The Apache Flink community is very happy to announce the release of Apache
Flink 1.12.3, which is the third bugfix release for the Apache Flink 1.12
series.
Apache Flink® is an open-source stream processing framework for
distributed, high-performing, always-available, and accurate data
interface change when they upgrade to 1.13+.
> > >
> > > Personally I think option 3 here is better because it does not really
> > > introduce any trouble to the users. The downside is that we do need to
> > > change the API of Kafka source in 1.12. Given that
Just to double check are the changes in the PR of Thomas even touching the
API or would that be another PR?
Or are the API changes contained to FLINK-20379?
On Wed, May 5, 2021 at 8:29 PM Arvid Heise wrote:
> After looking a bit more into it, I'm also +1.
>
> Let's merge it
Dear devs,
To address the licencing issue of 1.12.3 [1] and the misbundled scala 2.12,
I'm proposing to start releasing 1.12.4 on next Monday.
I'd volunteer as a release manager again.
Best,
Arvid
[1] https://issues.apache.org/jira/browse/FLINK-22555
Hi everyone,
Please review and vote on the release candidate #1 for the version 1.12.4,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
The complete staging area is available for your review, which includes:
* JIRA release notes [1],
*
I'd also like to have a fix for
https://issues.apache.org/jira/browse/FLINK-22686 that was reported today.
On Mon, May 17, 2021 at 11:52 AM Timo Walther wrote:
> Hi Konstantin,
>
> thanks for starting the discussion. From the Table API side, we also
> fixed a couple of critical issues already th
Hi Eron,
I think this is a useful addition for storage systems that act as
pass-through for Flink to reduce recovery time. It is only useful if you
combine it with regional fail-over as only a small part of the pipeline is
restarted.
A couple of thoughts on the implications:
1. Watermarks are clo
gt; >> > pipeline in the same Flink job similar to KafkaStream's #through.
> >> >
> >>
> >> I'd slightly disagree here. For example we're "materializing"
> change-logs
> >> produced by Flink pipeline into serving layer (random acc
Dear devs,
In the last couple of weeks, I have noticed that we are slacking a bit on
the components in PR/commit messages. I'd like to gather some feedback if
we still want to include them and if so, how we can improve the process of
finding the correct label.
My personal opinion: So far, I have
gt;>> - Submitted demo job
> > >>>
> > >>>
> > >>> On Sun, May 16, 2021 at 8:40 PM Dawid Wysakowicz <
> > dwysakow...@apache.org>
> > >>> wrote:
> > >>>
> > >>>> +1 (binding)
> > >>&
Hi Etienne,
I'm taking over and just left you a review. Sorry for the long delays.
Best,
Arvid
On Fri, May 21, 2021 at 11:25 AM Etienne Chauchot
wrote:
> Hi all,
>
> considering (see my email below) that the DataStream API is not fully
> functional yet (batch mode) and considering that the ne
Dear all,
The Apache Flink community is very happy to announce the release of Apache
Flink 1.12.4, which is the fourth bugfix release for the Apache Flink 1.12
series.
Apache Flink® is an open-source stream processing framework for
distributed, high-performing, always-available, and accurate data
ich is not efficient. With such new interface, we can also
> >> manage the watermark propagation much more easily.
> >>
> >> [1] https://pravega.io/blog/2019/11/08/pravega-watermarking-support/
> >> [2]
> >>
> https://github.com/pravega/fl
behavior is the same as for elements.
>
> Thanks,
> Eron
>
> On Tue, May 25, 2021 at 12:42 PM Arvid Heise wrote:
>
> > Hi Eron,
> >
> > I think the FLIP is crisp and mostly good to go. Some smaller
> > things/questions:
> >
> >1. SinkFunctio
e now? And are
> you able to drive the vote process?
>
> Thanks,
> Eron
>
>
> On Fri, May 28, 2021 at 4:40 AM Arvid Heise wrote:
>
> > Hi Eron,
> >
> > 1. fair point. It still feels odd to have writeWatermark in the
> > SinkFunction (it's supposed
+1 (binding)
Thanks Eron for driving this effort; it will open up new exciting use cases.
On Tue, Jun 1, 2021 at 7:17 PM Eron Wright
wrote:
> After some good discussion about how to enhance the Sink API to process
> watermarks, I believe we're ready to proceed with a vote. Voting will be
> ope
llowed? Or did I miss it?
> > Especially the StreamStatus part. For me it sounds like exposing
> watermarks
> > without letting the sink know that the stream can be idle is an
> incomplete
> > feature and can be very problematic/confusing for potential users.
> >
>
t; >
> > adapting to Flink's notion of idleness (e.g. in Pulsar source, it means
> > that no topics/partitions are assigned to a given sub-task); a similar
> > adaption would occur in the sink. In other words, I think it
> >
> > reasonable
> >
> > that a s
s his intent.
On Fri, Jun 4, 2021 at 3:43 PM Arvid Heise wrote:
> I think the core issue in this discussion is that we kind of assume that
> idleness is something universally well-defined. But it's not. It's a
> heuristic to advance data processing in event time where we wo
>
> Thank you all for the robust discussion. Do I have your support to proceed
> to enhance FLIP-167 with idleness callbacks and to proceed to a vote?
>
> Eron
>
>
> On Fri, Jun 4, 2021 at 9:08 AM Arvid Heise wrote:
>
> > While everything I wrote before is still valid, up
related to
> processing time. The clear example is partition assignment to subtasks,
> which probably motivated Flink's idleness functionality in the first place.
>
> On Fri, Jun 4, 2021 at 12:53 PM Arvid Heise wrote:
>
> > Hi Eron,
> >
> > Are you referri
;rise to the occasion" - treat event time in a
> 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 Ar
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 implementation.
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
sim
Hi Yangze,
I like the general approach to bind requirements to slotsharing groups. I
think the current approach is also flexible enough that a user could simply
use ParameterTool or similar to use config values and wire that with their
slotgroups, such that different requirements can be tested wit
Hi Tianxin,
I assigned you the ticket, so you could go ahead and create some POC PR. I
would like to understand the issue first a bit better and then give some
things to consider. In general, I see your point that in a potentially
infinitely running application keeping track of all read entities w
Hi devs,
While discussing "Watermark propagation with Sink API" and during
"[FLINK-18934] Idle stream does not advance watermark in connected stream",
we noticed some drawbacks on how Flink defines idle partitions currently.
To recap, idleness was always considered as a means to achieve progress
with
> >> Dawid that record 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 n
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
; For now I'd go with @Piotr's proposal to add the "drain" method only to
> the SinkFunction. We think they are not immediately necessary for any of
> the other UDFs.
>
> Best,
>
> Dawid
> On 09/06/2021 11:20, Arvid Heise wrote:
>
> I have not followed
eel :) `flush()` is kind of
> an industry standard for things like that. Furthermore I don't think
> `drain()` solves Till's concern (drain != stop + flush). `stopAndFlush()`
> would be better in this regard, but it also doesn't feel right. Maybe
> `finish()`?
>
> Pi
on't think we need to expose the ExternalResource. In the
> > builder of SlotSharingGroup, we can introduce a
> > #withExternalResource(String name, double value). Also, this interface
> > needs to be annotated as evolving.
> >
> > 4) Actually, I've mentioned it in
t understand what `drain()`
> is
>
> > all about without reading the java-doc, and afterwards, I would have an
>
> > impression that someone wanted to reinvent a wheel :) `flush()` is kind
> of
>
> > an industry standard for things like that. Furthermore I don't think
>
; > > > > >> already covered somewhere).
> > > > > >>
> > > > > >> Best, Piotrek
> > > > > >>
> > > > > >> czw., 3 cze 2021 o 16:12 Jark Wu napisał(a):
> > > > > >>
> > > &g
tion, automatically
> 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:
> >>
> >&g
LGTM +1 (binding) from my side.
On Tue, Jun 15, 2021 at 11:00 AM Yangze Guo wrote:
> Hi everyone,
>
> I'd like to start the vote of FLIP-169 [1]. This FLIP is discussed in
> the thread[2].
>
> The vote will be open for at least 72 hours. Unless there is an
> objection, I will try to close it by
github.com/apache/flink/compare/master...AHeise:junit5?expand=1
On Tue, Dec 1, 2020 at 9:54 AM Khachatryan Roman <
khachatryan.ro...@gmail.com> wrote:
> +1 for the migration
>
> (I agree with Dawid, for me the most important benefit is better support of
> parameterized tests)
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 Song
; Xingbo
> >
> > Yun Tang 于2021年6月17日周四 上午10:49写道：
> >
> > > Congratulations, Arvid
> > >
> > > Best
> > > Yun Tang
> > >
> > > From: Yun Gao
> > > Sent: Thursday, June 17, 2021 10
Hi Satish,
usually you would side-outputs [1] for that but afaik asyncIO doesn't
support that (yet).
So your option works well to use some union type. You can then chain a map
function that uses side-outputs.
[1]
https://ci.apache.org/projects/flink/flink-docs-master/docs/dev/datastream/side_outp
Hi Danny,
to add I'd propose to use the flink-connector-base package which has the
rough equivalent on source-side SourceReaderBase [1]. Since it's such a
handy base implementation, I'd like to see it directly in the main flink
repository.
For the actual connectors, I'm currently working on a pro
Hi Piotr,
to pick up this discussion thread again:
- This FLIP is about providing some base implementation for FLIP-143 sinks
that make adding new implementations easier, similar to the
SourceReaderBase.
- The whole availability topic will most likely be a separate FLIP. The
basic issue just poppe
Hi Eron,
I will check it tomorrow. Sorry for the delay. If someone beats me to that,
please go ahead.
On Mon, Jun 21, 2021 at 8:18 PM Eron Wright
wrote:
> Would someone be willing and able to review the PR which adds watermarks to
> the sink API?
>
> https://github.com/apache/flink/pull/15950
>
I think this is overall a good idea. So +1 from my side.
However, I'd like to put a higher priority on infrastructure then, in
particular docker image/artifact caches.
On Tue, Jun 22, 2021 at 11:50 AM Till Rohrmann wrote:
> Thanks for bringing this topic to our attention Xintong. I think your
>
+1 for dropping. Frankly speaking, I don't see it having any future (and D2iQ
agrees).
If there is a surprisingly huge demand, I'd try to evaluate plugins for it.
On Tue, Jun 22, 2021 at 11:46 AM Till Rohrmann wrote:
> I'd be ok with dropping support for Mesos if it helps us to clear our
> depe
Thanks for preparing the FLIP. +1 (binding) from my side.
On Tue, Jun 22, 2021 at 2:28 PM Hausmann, Steffen
wrote:
> Hi there,
>
> After the discussion in [1], I’d like to open a voting thread for FLIP-171
> [2], which proposes a base implementation for sinks that support async
> requests.
>
> T
+1 (binding)
On Mon, Jun 28, 2021 at 8:04 PM Piotr Nowojski wrote:
> +1 (binding)
>
> Piotrek
>
> pon., 28 cze 2021 o 16:01 Wenhao Ji napisał(a):
>
> > Hi everyone,
> >
> > I would like to start a vote on FLIP-172 [1] which was discussed in
> > this thread [2].
> > The vote will be open for at
>
> [1] https://www.testcontainers.org/test_framework_integration/junit_5/
> [2]
> https://github.com/testcontainers/testcontainers-java/issues/970#issuecomment-437273363
>
> --
> Best Regards,
>
> Qingsheng Ren
> Email: renqs...@gmail.com
> On Jun 16, 2021, 3:13 AM +080
+1 (binding)
Thank you and Thomas for driving this
On Thu, Jul 1, 2021 at 7:50 AM 蒋晓峰 wrote:
> Hi everyone,
>
>
>
>
> Thanks for all the feedback to Hybrid Source so far. Based on the
> discussion[1] we seem to have consensus, so I would like to start a vote on
> FLIP-150 for which the FLIP has
Looks good: +1 (binding)
On Tue, Jun 29, 2021 at 5:06 AM 刘建刚 wrote:
> +1 (binding)
>
> Best
> liujiangang
>
> Piotr Nowojski 于2021年6月29日周二 上午2:05写道：
>
> > +1 (binding)
> >
> > Piotrek
> >
> > pon., 28 cze 2021 o 12:48 Dawid Wysakowicz
> > napisał(a):
> >
> > > +1 (binding)
> > >
> > > Best,
>
+1 (binding)
On Wed, Jun 30, 2021 at 5:56 PM Qingsheng Ren wrote:
> Dear devs,
>
>
> As discussed in the thread[1], I’d like to start a vote on migrating the
> test framework of Flink project to JUnit 5.
>
>
> JUnit 5[2] provides many exciting new features that can simplify the
> development of
Congratulations!
On Wed, Jul 7, 2021 at 11:30 AM Till Rohrmann wrote:
> Congratulations, Guowei!
>
> Cheers,
> Till
>
> On Wed, Jul 7, 2021 at 9:41 AM Roman Khachatryan wrote:
>
> > Congratulations!
> >
> > Regards,
> > Roman
> >
> > On Wed, Jul 7, 2021 at 8:24 AM Rui Li wrote:
> > >
> > > Con
Congratulations!
On Wed, Jul 7, 2021 at 12:17 PM godfrey he wrote:
> Congratulations, Yang!
>
> Best,
> Godfrey
>
> Lijie Wang 于2021年7月7日周三 下午5:59写道：
>
> > Congratulations Yang!
> >
> > Till Rohrmann 于2021年7月7日周三 下午5:29写道：
> >
> > > Congratulations, Yang!
> > >
> > > Cheers,
> > > Till
> > >
>
Yay!
On Thu, Jul 8, 2021 at 10:02 AM Jiayi Liao wrote:
> Congratulations Yuan!
>
> Best,
> Jiayi Liao
>
> On Thu, Jul 8, 2021 at 3:55 PM Roman Khachatryan wrote:
>
> > Congratulations Yuan!
> >
> > Regards,
> > Roman
> >
> > On Thu, Jul 8, 2021 at 6:02 AM Yang Wang wrote:
> > >
> > > Congratul
Dear devs,
As a continuation and generalization of FLIP-33 (Standardize Connector
Metrics) [1], we'd like to discuss how we actually expose the standardized
operator metrics to users in terms of changes to the API.
Please check out the FLIP [2] and provide feedback.
Best,
Arvid
[1]
https://cwi
> > B. The EventTime is known only after the fetched record was parsed
> in
> > the RecordEmitter. In this case, the RecordEmitter needs to get the fetch
> > time of that particular record.
> > I am not sure when users set the LastFetchTime in the above two cases.
>
backlog. that would be very useful
>
>
> > G setPendingRecordsGauge(G pendingRecordsGauge);
>
>- In the Kafka source case, this is intended to capture the consumer lag
>(log head offset from broker - current record offset)? that could be
> used
>to capture the siz
Dear devs,
We recently discovered that StreamStatus and Idleness is insufficiently
defined [1], so I drafted a FLIP [3] to amend that situation. It would be
good to hear more opinions on that matter. Ideally, we can make the changes
to 1.14 as some newly added methods are affected.
Best,
Arvid
dered at the time).
> >> > >
> >> > > The concern at the time causing us to alter the definition to be
> >> "record
> >> > > idleness" in the final implementation was due to the existence of
> >> > periodic
> >> >
a):
> > >
> > > > Piotr, David, and Arvid, we've had an expansive discussion but
> > ultimately
> > > > the proposal is narrow. It is:
> > > > 1. When a watermark arrives at the sink operator, tell the sink
> > function.
>
splits" enumerator metric. I
> tried to publish those metrics for IcebergSourceEnumerator and ran into an
> issue [1]. I don't want to distract the discussion with the jira ticket.
>
> [1] https://issues.apache.org/jira/browse/FLINK-21000
>
> On Thu, Jul 15, 2021 at 1:
onnectors/flink-connector-base/src/main/java/org/apache/flink/connector/base/sink
>> > [2]
>> >
>> https://github.com/sthm/flink/blob/flip-171-177/flink-connectors/flink-connector-kinesis-171/src/main/java/software/amazon/flink/connectors/AmazonKinesisDataStreamSink.java
&
Dear devs,
today I'd like to start the discussion on the Sink API. I have drafted a
FLIP [1] with an accompanying PR [2].
This FLIP is a bit special as it's actually a few smaller Amend-FLIPs in
one. In this discussion, we should decide on the scope and cut out too
invasive steps if we can't reac
);
> }
>
> 2. Another question is: If users don't care about exactly once and the
> unification of stream and batch, how about letting users use
> `AsyncFunction` directly? I don’t have an answer either. I want to hear
> your suggestions.
>
> Best,
> Guowei
>
>
Hi all,
@Steven Wu
> Regarding "lastFetchTime" latency metric, I found Gauge to be less
> informative as it only captures the last sampling value for each metric
> publish interval (e.g. 60s).
> * Can we make it a histogram? Histograms are more expensive though.
> * Timer [1, 2] is cheaper as it
om/sthm/flink/blob/51614dc9371d6e352db768a404ba3cafddad08f0/flink-connectors/flink-connector-base/src/main/java/org/apache/flink/connector/base/sink/writer/AsyncSinkWriter.java#L155
>> [3]
>> https://github.com/sthm/flink/blob/51614dc9371d6e352db768a404ba3cafddad08f0/flink-connectors/flink-c
cular because we lack any switch
> to
> >> disable/enable metrics (and I think we are getting to a point where the
> >> metric system becomes unusable for heavy users because of that, where
> >> another histogram isn't helping).
> >>
> >> Overa
k status.
>
> Maybe the FLIP should spell out the expected behavior of the generic
> watermark generator (TimestampsAndWatermarksOperator). Should the
> generator ignore the upstream idleness signal? I believe it propagates the
> signal, even though it also generates its own sig
+1 (binding)
On Wed, Jul 21, 2021 at 1:55 PM Piotr Nowojski wrote:
> Hi everyone,
>
> I would like to start a vote on the FLIP-182 [1] which was discussed in
> this
> thread [2].
> The vote will be open for at least 72 hours unless there is an objection
> or not enough votes.
>
> Best,
> Piotrek
ream).
> > In fact, I think this is the most important issue. We lack the function
> of
> > supporting sub-topology at the API layer, which is very inconvenient. For
> > examplestream.sinkTo(AsyncSinkTopoloyBuilder), what do you think?
> > ```java
> >
, Long timestamp, Metadata metadata). This also
> makes a natural alignment because the RecordsWithSplitIds also returns a
> Metadata associated with the record, which can be used by RecordEmitter as
> well as the SourceOutput.
>
> What do you think?
>
> Thanks,
>
> Jiangjie
Hi folks,
To move on with the FLIP, I will cut out eventTimeFetchLag out of scope and
go ahead with the remainder.
I will open a VOTE later to today.
Best,
Arvid
On Wed, Jul 28, 2021 at 8:44 AM Arvid Heise wrote:
> Hi Becket,
>
> I have updated the PR according to your suggestion (
Dear devs,
I'd like to open a vote on FLIP-179: Expose Standardized Operator Metrics
[1] which was discussed in this thread [2].
The vote will be open for at least 72 hours unless there is an objection
or not enough votes.
The proposal excludes the implementation for the currentFetchEventTimeLag
> > }
>
> Maybe we can move one step further to make it "metadataOfCurrentRecord()"
> as I mentioned above.
>
> Thanks,
>
> Jiangjie (Becket) QIn
>
> On Fri, Jul 30, 2021 at 3:00 PM Arvid Heise wrote:
>
> > Hi folks,
> >
> > To move on wit
Hi all,
I'd like to start a vote on FLIP-177: Extend Sink API [1] which provides
small extensions to the Sink API introduced through FLIP-143.
The vote will be open for at least 72 hours unless there is an objection or
not enough votes.
Note that the FLIP was larger initially and I cut down all
a
fter all, `Mailbox` has decided to be
> exposed :-) ). It’s just that I personally prefer to combine some simple
> functions to complete a more advanced function.
> Best,
> Guowei
>
>
> On Sat, Jul 24, 2021 at 3:38 PM Arvid Heise wrote:
>
> > Just to reiterate on Piot
internal seems to me
> the
> > better choice right now. Moreover, as Arvid said the downstream
> application
> > can derive the WatermarkStatus on their own depending on its business
> > logic.
> >
> > Cheers,
> > Till
> >
> > On Fri, Jul 23, 2021 a
ket) Qin
> > >
> > > On Sat, Jul 31, 2021 at 12:08 PM Steven Wu
> wrote:
> > >
> > >> +1 (non-binding)
> > >>
> > >> On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise wrote:
> > >>
> > >>> Dear devs,
> >
t Qin wrote:
> Personally speaking, it is intuitive for me to set a gauge in MetricGroup.
> So I am fine with set*Gauge pattern as long as the method is in
> *MetricGroup class.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> On Tue, Aug 3, 2021 at 7:24 PM Arvid Heise wrote:
t,
> Guowei
>
>
> On Mon, Aug 2, 2021 at 4:04 PM Danny Cranmer
> wrote:
>
> > +1 (binding)
> >
> > On Mon, Aug 2, 2021 at 12:42 AM Thomas Weise wrote:
> >
> > > +1 (binding)
> > >
> > >
> > > On Fri, Jul 30, 2021 at 5:05
Dear devs,
I'd like to open a vote on FLIP-180: Adjust StreamStatus and Idleness
definition [1] which was discussed in this thread [2].
The vote will be open for at least 72 hours unless there is an objection or
not enough votes.
Best,
Arvid
[1]
https://cwiki.apache.org/confluence/display/FLINK
101 - 200 of 429 matches
Mail list logo
