Hi Zhijiang,
Thanks for the quick reply!
For the 1st question, please allow me to confirm, that when doing
asynchronous checkpointing, disk spilling should happen in background in
parallel with receiving/sending new data, or else it would become
synchronous, right? Based on such assumption, some
About 1:
1. ManagedMemory's total could get from TaskExecutorResourceSpec.
2. ManagedMemory's used registers in SlotMetricGroup is ok. As there's no
MetricGroup for the slot, so we need to create SlotMetricGroup.
Till Rohrmann 于2020年2月25日周二 下午6:58写道：
> Thanks for creating this FLIP Yadong. I
Hi Yu,
Thanks for concerning of this FLIP and sharing your thoughts! Let me try to
answer some below questions.
1. Yes, the asynchronous checkpointing should be part of whole process and be
supported naturally. As for the network memory concern,
the inflight-buffers would be spilled into persi
Jeff Zhang created FLINK-16286:
--
Summary: Support select from nothing
Key: FLINK-16286
URL: https://issues.apache.org/jira/browse/FLINK-16286
Project: Flink
Issue Type: New Feature
Affects V
Zhijiang created FLINK-16285:
Summary: Refactor SingleInputGate#setInputChannel to remove
IntermediateResultPartitionID argument
Key: FLINK-16285
URL: https://issues.apache.org/jira/browse/FLINK-16285
Pro
Zhijiang created FLINK-16284:
Summary: Refactor SingleInputGate#setInputChannel to remove
IntermediateResultPartitionID argument
Key: FLINK-16284
URL: https://issues.apache.org/jira/browse/FLINK-16284
Pro
Hi All,
Sorry for being late to the discussion. I've gone through the latest FLIP
document and have below questions/suggestions:
1. Do we support asynchronous checkpointing on the in-flight data?
* From the doc the answer seems to be yes (state-based storage for the
first version), and if so,
Thanks for the detailed PR advice, I would separate the commits as clear as
possible to help the code reviewing.
Cheers,
Canbin Zheng
tison 于2020年2月25日周二 下午10:11写道：
> Thanks for your clarification Yang! We're on the same page.
>
> Best,
> tison.
>
>
> Yang Wang 于2020年2月25日周二 下午10:07写道：
>
>> H
Robert Metzger created FLINK-16283:
--
Summary: NullPointerException in GroupAggProcessFunction
Key: FLINK-16283
URL: https://issues.apache.org/jira/browse/FLINK-16283
Project: Flink
Issue Typ
Hi Yadong,
thanks for creating this FLIP. I like the idea of exposing more
cluster information to the user.
I share Xintong's concerns that we are about to rework the cluster
entrypoint's memory management. It might make sense to wait for these
changes before starting this effort. Otherwise, we m
Nico Kruber created FLINK-16282:
---
Summary: Wrong exception using DESCRIBE SQL command
Key: FLINK-16282
URL: https://issues.apache.org/jira/browse/FLINK-16282
Project: Flink
Issue Type: Bug
Leonard Xu created FLINK-16281:
--
Summary: parameters 'maxRetryTimes' can not work in
JDBCUpsertTableSink
Key: FLINK-16281
URL: https://issues.apache.org/jira/browse/FLINK-16281
Project: Flink
I
Hi Yadong,
thanks for creating this FLIP. I like the idea to make the web-ui
information richer wrt to subtask attempt information.
I have a comment concerning the SubtasksTimesHandler: Should we change the
response type SubtasksTimeInfo so that it simply contains an
array of SubtaskTimeInfo? One
Jiaqi Li created FLINK-16280:
Summary: Fix sample code errors in the documentation about
elasticsearch connector.
Key: FLINK-16280
URL: https://issues.apache.org/jira/browse/FLINK-16280
Project: Flink
Thanks for your clarification Yang! We're on the same page.
Best,
tison.
Yang Wang 于2020年2月25日周二 下午10:07写道：
> Hi tison,
>
> I do not mean to keep two decorator at the same. Since the two decorators
> are
> not api compatible, it is meaningless. I am just thinking how to organize
> the
> commit
Hi tison,
I do not mean to keep two decorator at the same. Since the two decorators
are
not api compatible, it is meaningless. I am just thinking how to organize
the
commits/PRs to make the review easier. The reviewers may need some context
to get the point.
Best,
Yang
tison 于2020年2月25日周二 下午8
Wenlong Lyu created FLINK-16279:
---
Summary: Per job Yarn application leak in normal execution mode.
Key: FLINK-16279
URL: https://issues.apache.org/jira/browse/FLINK-16279
Project: Flink
Issue T
None none created FLINK-16278:
-
Summary: Document new settings for MaxMetaSpace in 1.10
Key: FLINK-16278
URL: https://issues.apache.org/jira/browse/FLINK-16278
Project: Flink
Issue Type: Improvem
Benoît Paris created FLINK-16277:
Summary: StreamTableEnvironment.toAppendStream fails with Decimal
types
Key: FLINK-16277
URL: https://issues.apache.org/jira/browse/FLINK-16277
Project: Flink
Zhu Zhu created FLINK-16276:
---
Summary: Introduce factory methods to create DefaultScheduler for
testing
Key: FLINK-16276
URL: https://issues.apache.org/jira/browse/FLINK-16276
Project: Flink
Issue
The process in my mind is somehow like this commit[1] which belongs to this
pr[2]
that we firstly introduce the new implementation and then replace it with
the original
one. The difference is that these two versions of decorators are not api
compatible
while adding a switch for such an internal abs
I agree for separating commits we can have multiple commits that firstly
add the new parameters
and decorators, and later replace current decorators with new decorators
which are well
unit tested.
However, it makes no sense we have two codepaths from FlinkKubeClient to
decorators
since these two
I think if we could, splitting into as many PRs as possible is good. Maybe
we could
introduce the new designed decorators and parameter parser first, and leave
the existing
decorators as legacy. Once all the new decorators is ready and well tested,
we could
remove the legacy codes and use the new d
Rui Li created FLINK-16275:
--
Summary: AggsHandlerCodeGenerator can fail with custom module
Key: FLINK-16275
URL: https://issues.apache.org/jira/browse/FLINK-16275
Project: Flink
Issue Type: Bug
Hi Yadong,
thanks for creating this FLIP. I like the idea to show the user if some
slots are missing in order to run an operator.
However, since we plan to rework the scheduling part and also how resources
are acquired extensively, I'm not entirely sure whether we should add this
functionality no
Thanks for creating this FLIP Yadong. I think your proposal makes it much
easier for the user to understand what's happening on Flink TaskManager's.
I have some comments:
1. Some of the newly introduced metrics involve computations on the
TaskManager. I would like to avoid additional computations
Hi, Till,
Great thanks for your advice, I totally agree with you to split the changes
up in as many PRs as possible. The part of "Parameter Parser" is trivial so
that we prefer to make one PR to avoid adapting a lot of pieces of code
that would be deleted immediately with the following decorator r
late +1 (binding).
Cheers,
Till
On Tue, Feb 25, 2020 at 4:55 AM Yadong Xie wrote:
> Thanks all for the votes.
>
> So far, we have
>
> - 3 binding +1 votes (Kurt, Jark, zhijiang)
> - 4 non-binding +1 votes (Congxian, Wangyang, Benchao, Yun Gao)
> - No -1 votes
>
> The voting time has past and th
late +1 (binding)
Cheers,
Till
On Tue, Feb 25, 2020 at 4:46 AM Yadong Xie wrote:
> Thanks all for the votes.
>
> So far, we have
>
> - 4 binding +1 votes (Kurt, Jark, jincheng, Zhu Zhu)
> - 5 non-binding +1 votes (Yang Wang, Xintong Song, lining, Yangze, zhenya)
> - No -1 votes
>
> The voting t
+1 (binding)
Cheers,
Till
On Mon, Feb 24, 2020 at 3:04 AM zoudan wrote:
> +1 (non-binding)
>
> Best,
> Dan Zou
>
Thanks Xintong for the explanation.
The FLIP looks good to me now. +1 from my side.
Best,
Jark
On Tue, 25 Feb 2020 at 15:46, Xintong Song wrote:
> @Jark
>
> First, let me try to clarify that, while this FLIP is about adding JM
> metrics, the discussion of having different colors distinguishing
Just a quick meta comment concerning one PR vs. two PRs vs. multiple PRs: I
would recommend to split the changes up in as many PRs as possible. In my
experience, a large uber PR usually won't be reviewed as thoroughly because
of the sheer size. Moreover, the reviewing usually takes much longer. Of
Hi Yadong,
Thanks for the updating. LGTM now.
+1 (non-binding)
Yadong Xie 于2020年2月25日周二 下午4:41写道：
> Hi Kurt
>
> There will be no differences between batch jobs and stream jobs in
> subtask-attempt level in the UI
> The only differences are in the vertex timeline, I have added a screenshot
> o
Hi Kurt
There will be no differences between batch jobs and stream jobs in
subtask-attempt level in the UI
The only differences are in the vertex timeline, I have added a screenshot
of the batch job in the FLIP-100 since the batch job will disappear from
the list after it finished soon.
here is th
+1 for supporting Python UDF in Java/Scala Table API.
This is a great feature and would be helpful for python users!
Best,
Dan Zou
Hi all,
I realized that the FLIP missed the information about *WatermarkOutput*. It
allows users to emit watermark and indicate the idleness of the source, and
is the super class of *SourceOutput.* I have added the related information
to the FLIP wiki. The key information is following:
- *Wa
36 matches
Mail list logo
