Jark Wu created FLINK-21997:
---
Summary: Add back missing jdbc.md zh docs
Key: FLINK-21997
URL: https://issues.apache.org/jira/browse/FLINK-21997
Project: Flink
Issue Type: Task
Components:
Stephan Ewen created FLINK-21996:
Summary: Transient RPC failure without TaskManager failure can
lead to split assignment loss
Key: FLINK-21996
URL: https://issues.apache.org/jira/browse/FLINK-21996
P
Dawid Wysakowicz created FLINK-21995:
Summary:
YARNSessionFIFOSecuredITCase>YARNSessionFIFOITCase.checkForProhibitedLogContents:
File channel manager has shutdown.
Key: FLINK-21995
URL: https://issues.apache.
I agree with Chesnay that we also used Blocker as a kind of reminder for
things which should happen but are not super time critical. Other examples
are for example the deprecation of APIs or changing of default values. I
admit that these examples could also be changed right away and wouldn't
benefi
+1 for the proposal. Thanks for driving it Konstantin.
Cheers,
Till
On Fri, Mar 26, 2021 at 9:58 AM Roman Khachatryan wrote:
> +1,
>
> thanks for this improvement Konstantin!
>
> Regards,
> Roman
>
> On Fri, Mar 26, 2021 at 8:49 AM Arvid Heise wrote:
> >
> > +1 from my side.
> > Thanks for pr
Thank you Thomas! I'll definitely check the issue you linked.
Best,
Dawid
On 23/03/2021 20:35, Thomas Weise wrote:
> Hi Dawid,
>
> Thanks for the heads up.
>
> Regarding the "Rebase and merge" button. I find that merge option useful,
> especially for small simple changes and for backports. The f
+1 for officially deprecating this component for the 1.13 release.
Cheers,
Till
On Thu, Mar 25, 2021 at 1:49 PM Konstantin Knauf wrote:
> Hi Matthias,
>
> Thank you for following up on this. +1 to officially deprecate Mesos in
> the code and documentation, too. It will be confusing for users if
Hi Chesnay:
If the server side expects the serialized execution config never be null, I
think it just equals that we must setExecutionConfig somewhere either in the
constructor or after the jobGraph has been instantiated at least once.
The current implementation sets ExecutionConfig in the constr
Dian Fu created FLINK-21994:
---
Summary: Support FLIP-27 based FileSource connector in PyFlink
DataStream API
Key: FLINK-21994
URL: https://issues.apache.org/jira/browse/FLINK-21994
Project: Flink
I
Till Rohrmann created FLINK-21993:
-
Summary: Remove LocalCollectionOutputFormat from code base
Key: FLINK-21993
URL: https://issues.apache.org/jira/browse/FLINK-21993
Project: Flink
Issue Typ
It may cause certain metric backends to reject metrics due to names
being too long.
IIRC we have seen this with graphite in particular.
In some cases removing this truncation can also impact the transfer of
metrics due to size limitations.
Overall, I would advise you to not remove this trunca
It just initializes the field to ensure it is set when it is
deserialized server-side.
There is neither a guarantee nor requirement that the APIs must set the
ExecutionConfig at least once, so this ensures that on the server-side
the execution config is never null.
On 3/26/2021 11:18 AM, Zhang
Arvid Heise created FLINK-21992:
---
Summary: Investigate potential buffer leak in unaligned checkpoint
Key: FLINK-21992
URL: https://issues.apache.org/jira/browse/FLINK-21992
Project: Flink
Issue
FLINK-21152 is special because we usually know quite early that it must
be done (e.g., because we bump some dependency in flink-shaded at the
start of the release cycle), but only do it shortly before a release to
avoid wasting time on multiple flink-shaded release cycles for a single
Flink rel
Hello:
I was recently study the code about how the JobGraph generates. I noticed
in the constructor of StreamingJobGraphGenerator, it constructs a JobGraph. And
in the constructor of JobGraph, it called setExecutionConfig(new
ExecutionConfig()) which serialized a default ExecutionConfig. T
My proposal does not have an answer for this.
Is "Blocker" often used for this, right now? What is special about
FLINK-21152 compared to other important bug fixes/features for the release
that makes it a Blocker?
It also ties a bit into the question of what "fixVersion" means. I think,
right now
That's a fair point, but then that raises the question how tasks are
documented that /must/ be done for a release /at some point/.
The current approach allows me to easily setup a signal for the Release
Manager that this ticket must be completed. How would that work in your
proposal?
On 3/26/2
jackylau created FLINK-21991:
Summary: flink varchar which exposes to users it not unified
Key: FLINK-21991
URL: https://issues.apache.org/jira/browse/FLINK-21991
Project: Flink
Issue Type: Bug
ming li created FLINK-21990:
---
Summary: Double check Task status when perform checkpoint.
Key: FLINK-21990
URL: https://issues.apache.org/jira/browse/FLINK-21990
Project: Flink
Issue Type: Bug
A
+1,
thanks for this improvement Konstantin!
Regards,
Roman
On Fri, Mar 26, 2021 at 8:49 AM Arvid Heise wrote:
>
> +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 adju
Hi Chesnay,
a blocker is currently defined in the Flink Confluence as a "needs to be
resolved before a release (matched based on fix versions)" whereas I was
thinking of it as a "someone needs to stop their work to fix this" kind of
thing. In the proposal I shared a blocker is therefore defined as
FLINK-21152 is an example of a blocker issue that can remain stale for
months.
On 3/26/2021 8:46 AM, Konstantin Knauf wrote:
Hi Arvid,
I agree that this should never happen for blockers. My thinking was that if
an unassigned blocker is deprioritized after 1 day it also forces us to
find someon
+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 Arvid,
I agree that this should never happen for blockers. My thinking was that if
an unassigned blocker is deprioritized after 1 day it also forces us to
find someone to work on the blocker right away, which we should do anyway
if it is blocker.
Thanks,
Konstantin
On Fri, Mar 26, 2021 at 8:
+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 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, Mar 24, 2021 at 11:15 AM Konstantin Knauf
wrote:
> > When/how are labels removed?
>
> Manually by the user
26 matches
Mail list logo
