h. @Becket Qin
> are you okay with the setLastFetchTimeGauge explanation or do you have
> alternative ideas?
>
> Best,
>
> Arvid
>
> On Fri, Jul 16, 2021 at 8:13 PM Steven Wu wrote:
>
> > To avoid confusion, can we either rename "SourceMetricGroup" to &
> if a failure happens after sequence of finish() -> snapshotState(), but
before notifyCheckpointComplete(), we will restore such a state and we
might end up sending some more records to such an operator.
I probably missed sth here. isn't this the case today already? Why is it a
concern for the pr
+1 (non-binding)
On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise wrote:
> 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
Fabian, thanks a lot for the proposal and starting the discussion.
We probably should first describe the different causes of small files and
what problems was this proposal trying to solve. I wrote a data shuffling
proposal [1] for Flink Iceberg sink (shared with Iceberg community [2]). It
can add
> although I think only using a customizable shuffle won't address the
generation of small files. One assumption is that at least the sink generates
one file per subtask, which can already be too many. Another problem is
that with low checkpointing intervals, the files do not meet the required
siz
Till, thank you for your immense contributions to the project and the
community.
On Mon, Feb 28, 2022 at 9:16 PM Xintong Song wrote:
> Thanks for everything, Till. It has been a great honor working with you.
> Good luck with your new chapter~!
>
> Thank you~
>
> Xintong Song
>
>
>
> On Tue, Mar
> A use case for this might be when you want to rollback a framework
upgrade (after some time) due to e.g. a performance
or stability issue.
Downgrade (that Konstantin called out) is an important and realistic
scenario. It will be great to support backward compatibility for savepoint
or at least d
le pointing out
> what the community commits to maintain going forward (e.g. "happens to
> work" vs. "guaranteed to work")
>
> In general, the table is quite large. Would it make sense to order the
> releases in reverse order (assuming that the table is more releva
estore
> from the savepoint taken the new Flink version instead of the previous
> savepoint, is that we want to minimize the source rewind?
>
> Best,
> Congxian
>
>
> Steven Wu 于2020年6月3日周三 上午9:08写道：
>
> > Current Flink documentation is actually pretty clear about n
+1 (non-binding)
- rolled out to thousands of router jobs in our test env
- tested with a large-state job. Did simple resilience and
checkpoint/savepoint tests. General performance metrics look on par.
- tested with a high-parallelism stateless transformation job. General
performance metrics look
can we add these two? They can make fine-grained recovery more consistent.
https://issues.apache.org/jira/browse/FLINK-8042
https://issues.apache.org/jira/browse/FLINK-8043
On Tue, Jan 16, 2018 at 8:35 AM, Timo Walther wrote:
> @Jincheng: Yes, I think we should include the two Table API PRs.
>
Can someone grant me the contributor permission? we are thinking about
contributing to FLINK-9061. My jira id is "stevenz3wu"
Thanks,
Steven
; >>
> >> On Thu, Apr 26, 2018 at 4:40 PM, TechnoMage
> wrote:
> >>
> >>> Contributor permission is only granted after siginificant
> contributions.
> >>> The route to contributing is to use pull requests and have the commits
> >>> rev
101 - 113 of 113 matches
Mail list logo
