[jira] [Created] (FLINK-35428) WindowJoinITCase#testInnerJoin failed on AZP as NPE
Weijie Guo created FLINK-35428: -- Summary: WindowJoinITCase#testInnerJoin failed on AZP as NPE Key: FLINK-35428 URL: https://issues.apache.org/jira/browse/FLINK-35428 Project: Flink Issue Type: Bug Components: Build System / CI Affects Versions: 1.20.0 Reporter: Weijie Guo https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=59751&view=logs&j=a9db68b9-a7e0-54b6-0f98-010e0aff39e2&t=cdd32e0b-6047-565b-c58f-14054472f1be&l=11944 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FLINK-35429) We don't need introduce getFlinkConfigurationOptions for SqlGatewayRestEndpointFactory#Context
Weijie Guo created FLINK-35429: -- Summary: We don't need introduce getFlinkConfigurationOptions for SqlGatewayRestEndpointFactory#Context Key: FLINK-35429 URL: https://issues.apache.org/jira/browse/FLINK-35429 Project: Flink Issue Type: Bug Reporter: Weijie Guo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FLINK-35430) ZoneId is not passed to DebeziumJsonSerializationSchema
LvYanquan created FLINK-35430: - Summary: ZoneId is not passed to DebeziumJsonSerializationSchema Key: FLINK-35430 URL: https://issues.apache.org/jira/browse/FLINK-35430 Project: Flink Issue Type: Improvement Components: Flink CDC Affects Versions: cdc-3.2.0 Reporter: LvYanquan Fix For: cdc-3.2.0 ZoneId is used to convert TIMESTAMP_WITH_LOCAL_TIME_ZONE type to specific time zone, but DebeziumJsonSerializationSchema does not used the user-defined zoneid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FLINK-35431) Migrate references in Flink CDC documentation from Debezium 1.9 to 2.0
Zhongqiang Gong created FLINK-35431: --- Summary: Migrate references in Flink CDC documentation from Debezium 1.9 to 2.0 Key: FLINK-35431 URL: https://issues.apache.org/jira/browse/FLINK-35431 Project: Flink Issue Type: Improvement Components: Flink CDC Affects Versions: cdc-3.2.0 Reporter: Zhongqiang Gong Backgroud: The website has taken down the documentation for versions before 2.0. And flink cdc document ci failed. Discuss link: https://lists.apache.org/thread/twdpd4bvoxtmjd0tykk7hs73hx4rm6yv -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FLINK-35432) Support catch modify-event for mysql-cdc
hk__lrzy created FLINK-35432:
Summary: Support catch modify-event for mysql-cdc
Key: FLINK-35432
URL: https://issues.apache.org/jira/browse/FLINK-35432
Project: Flink
Issue Type: Improvement
Components: Flink CDC
Reporter: hk__lrzy
Now users common use sql like to modify the column type in MySQL.
{code:java}
Alter table MODIFY COLUMN `new_name` new_type{code}
Flink-CDC use *CustomAlterTableParserListener* to parse the ddl and wrap it as
ChangeEevent now. But i noticed that *CustomAlterTableParserListener* not
implement the method *enterAlterByModifyColumn* and
{*}exitAlterByModifyColumn{*}, and it will cause we can't received the
*AlterColumnTypeEvent* now
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FLINK-35433) Provide a config parameter to set {{publishNotReadyAddresses}} option for the jobmanager's RPC Kubernetes service
Pavel created FLINK-35433:
-
Summary: Provide a config parameter to set
{{publishNotReadyAddresses}} option for the jobmanager's RPC Kubernetes service
Key: FLINK-35433
URL: https://issues.apache.org/jira/browse/FLINK-35433
Project: Flink
Issue Type: Improvement
Components: Deployment / Kubernetes
Reporter: Pavel
*Context:*
In native Kubernetes deployment Flink creates a headless service for
JobManager's RPC calls. The description down below is only relevant for Flink
deployment in Application mode.
When there are {{livenessProbe}} and/or {{readinessProbe}} are defined with
{{{}initialDelaySeconds{}}}, created instances of TaskManager have to wait
until JobManager's probes are green, before they are able to connect to the
JobManager.
Probes configuration:
{code:yaml}
- name: flink-main-container
livenessProbe:
httpGet:
path: /jobs/overview
port: rest
scheme: HTTP
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 6
successThreshold: 1
timeoutSeconds: 5
readinessProbe:
httpGet:
path: /jobs/overview
port: rest
scheme: HTTP
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 6
successThreshold: 1
timeoutSeconds: 5
{code}
During this period there are log messages in the TaskManager like:
{code:java}
Failed to connect to [dev-pipeline.dev-namespace:6123] from local address
[dev-pipeline-taskmanager-1-1/11.41.6.81] with timeout [200] due to:
dev-pipeline.dev-namespace
{code}
*Issue:*
Because initialization time of different Flink jobs (read: Flink deployments)
can vary in a wide range, it would be convenient to have a common configuration
for {{livenessProbe}} and/or {{readinessProbe}} for all deployments, which will
then cover the worst case, instead of tuning it for every deployment. On the
other hand, it would be nice to reduce the job's bootstrap time as a whole,
because the jobs' re-deployment in our case happens often and it affects
response time of incoming requests from clients.
*Solution:*
To reduce the job's bootstrap time as a whole one solution could be to set
{{publishNotReadyAddresses}} flag via config parameter in jobmanager's RPC
Kubernetes service, so that created instance of a taskmanager can connect to
the jobmanager immediately.
Publishing "not ready" JobManager's RPC should not cause any issue, because the
TaskManager instances in Kubernetes native deployment are created by a
ResourceManager, which is part of the JobManager, which in turn guarantees,
that JobManager is ready and ExecutionGraph was built successfully when a
TaskManager is starting.
Making this flag optional guarantees, that such approach will work correctly,
when the flag is disabled and JobManager High Availability is defined, which in
turn involves the leader election.
_Affected Classes:_
- {{org.apache.flink.kubernetes.kubeclient.services.HeadlessClusterIPService}}
- by adding one line
{{.withPublishNotReadyAddresses(kubernetesJobManagerParameters.isPublishNotReadyAddresses())}}
in {{Service buildUpInternalService(
KubernetesJobManagerParameters kubernetesJobManagerParameters)}}
- {{org.apache.flink.kubernetes.configuration.KubernetesConfigOptions}} - by
adding something like
{{kubernetes.jobmanager.rpc.service.publish-not-ready-addresses}} option
-
{{org.apache.flink.kubernetes.kubeclient.parameters.KubernetesJobManagerParameters}}
- by adding the get method for the parameter: {{public boolean
isPublishNotReadyAddresses() \{ return
flinkConfig.getBoolean(KubernetesConfigOptions.KUBERNETES_JOBMANAGER_RPC_SERVICE_PUBLISH_NOT_READY_ADDRESSES);
}}}
- Tests to cover the new parameter
If there is a decision, that such improvement worth to be part of Flink, I am
ready to provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FLINK-35434) Support pass exception in StateExecutor to runtime
Feifan Wang created FLINK-35434: --- Summary: Support pass exception in StateExecutor to runtime Key: FLINK-35434 URL: https://issues.apache.org/jira/browse/FLINK-35434 Project: Flink Issue Type: Sub-task Components: Runtime / State Backends Reporter: Feifan Wang Exception may thrown when _StateExecutor_ execute the state request , such as a IOException. We should pass the exception to runtime then failed the job in this situation. _InternalStateFuture#completeExceptionally()_ will be added as [discussion here|https://github.com/apache/flink/pull/24739#discussion_r1590633134]. And then, _ForStWriteBatchOperation_ and _ForStGeneralMultiGetOperation_ will call this method when exception occurred. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FLINK-35435) [FLIP-451] Introduce timeout configuration to AsyncSink
Ahmed Hamdy created FLINK-35435: --- Summary: [FLIP-451] Introduce timeout configuration to AsyncSink Key: FLINK-35435 URL: https://issues.apache.org/jira/browse/FLINK-35435 Project: Flink Issue Type: Improvement Components: Connectors / Common Reporter: Ahmed Hamdy Fix For: 1.20.0 Implementation Ticket for: https://cwiki.apache.org/confluence/display/FLINK/FLIP-451%3A+Introduce+timeout+configuration+to+AsyncSink+API -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [DISCUSS] FLIP-443: Interruptible watermark processing
Hi Zakelly,
I've thought about it a bit more, and I think only `#execute()` methods
make the most sense to be used when implementing operators (and
interruptible mails), so I will just add `MailOptions` parameters only to
them. If necessary, we can add more in the future.
I have updated the FLIP. If it looks good to you, I would start a voting
thread today/tomorrow.
Best,
Piotrek
czw., 23 maj 2024 o 09:00 Zakelly Lan napisał(a):
> Hi Piotrek,
>
> Well, compared to this plan, I prefer your previous one, which is more in
> line with the intuition for executors' API, by calling `execute` directly.
> Before the variants get too much, I'd suggest we only do minimum change for
> only "interruptible".
>
> My original thinking is, doubling each method could result in a scenario
> where new methods lack callers. But like you said, for the sake of
> completeness, I could accept the doubling method plan.
>
>
> Thanks & Best,
> Zakelly
>
> On Wed, May 22, 2024 at 5:05 PM Piotr Nowojski
> wrote:
>
> > Hi Zakelly,
> >
> > > I suggest not doubling the existing methods. Only providing the
> following
> > one is enough
> >
> > In that case I would prefer to have a complete set of the methods for the
> > sake of completeness. If the number of variants is/would be getting too
> > much, we could convert the class into a builder?
> >
> >
> >
> mailboxExecutor.execute(myThrowingRunnable).setInterriptuble().description("bla
> > %d").arg(42).submit();
> >
> > It could be done in both in the future, if we would ever need to add even
> > more methods, or I could do it now. WDYT?
> >
> > Best,
> > Piotrek
> >
> > śr., 22 maj 2024 o 08:48 Zakelly Lan napisał(a):
> >
> > > Hi Piotrek,
> > >
> > > `MailOptions` looks good to me. I suggest not doubling the existing
> > > methods. Only providing the following one is enough:
> > >
> > > void execute(
> > > > MailOptions mailOptions,
> > > > ThrowingRunnable command,
> > > > String descriptionFormat,
> > > > Object... descriptionArgs);
> > >
> > >
> > > WDYT?
> > >
> > >
> > > Best,
> > > Zakelly
> > >
> > >
> > > On Wed, May 22, 2024 at 12:53 AM Piotr Nowojski
> > > wrote:
> > >
> > > > Hi Zakelly and others,
> > > >
> > > > > 1. I'd suggest also providing `isInterruptable()` in `Mail`, and
> the
> > > > > continuation mail will return true. The FLIP-425 will leverage this
> > > queue
> > > > > to execute some state requests, and when the cp arrives, the
> operator
> > > may
> > > > > call `yield()` to drain. It may happen that the continuation mail
> is
> > > > called
> > > > > again in `yield()`. By checking `isInterruptable()`, we can skip
> this
> > > > mail
> > > > > and re-enqueue.
> > > >
> > > > Do you have some suggestions on how `isInterruptible` should be
> > defined?
> > > > Do we have to double the amount of methods in the `MailboxExecutor`,
> to
> > > > provide versions of the existing methods, that would enqueue
> > > > "interruptible"
> > > > versions of mails? Something like:
> > > >
> > > > default void execute(ThrowingRunnable
> command,
> > > > String description) {
> > > > execute(DEFAULT_OPTIONS, command, description);
> > > > }
> > > >
> > > > default void execute(MailOptions options, ThrowingRunnable > extends
> > > > Exception> command, String description) {
> > > > execute(options, command, description, EMPTY_ARGS);
> > > > }
> > > >
> > > > default void execute(
> > > > ThrowingRunnable command,
> > > > String descriptionFormat,
> > > > Object... descriptionArgs) {
> > > > execute(DEFAULT_OPTIONS, command, descriptionFormat,
> > > > descriptionArgs);
> > > > }
> > > >
> > > >void execute(
> > > > MailOptions options,
> > > > ThrowingRunnable command,
> > > > String descriptionFormat,
> > > > Object... descriptionArgs);
> > > >
> > > >public static class MailOptions {
> > > > (...)
> > > > public MailOptions() {
> > > > }
> > > >
> > > > MailOptions setIsInterruptible() {
> > > > this.isInterruptible = true;
> > > > return this;
> > > > }
> > > > }
> > > >
> > > > And usage would be like this:
> > > >
> > > > mailboxExecutor.execute(new MailOptions().setIsInterruptible(), ()
> -> {
> > > > foo(); }, "foo");
> > > >
> > > > ?
> > > >
> > > > Best,
> > > > Piotrek
> > > >
> > > > czw., 16 maj 2024 o 11:26 Rui Fan <1996fan...@gmail.com> napisał(a):
> > > >
> > > > > Hi Piotr,
> > > > >
> > > > > > we checked in the firing timers benchmark [1] and we didn't
> observe
> > > any
> > > > > > performance regression.
> > > > >
> > > > > Thanks for the feedback, it's good news to hear that. I didn't
> notice
> > > > > we already have fireProcessingTimers benchmark.
> > > > >
> > > > > If so, we can follow it after this FLIP is merged.
> > > > >
> > > > > +1 for this FLIP.
> > > > >
> > > > > Best,
> > > > > Rui
> > > > >
> > > > > On Thu, May 1
[jira] [Created] (FLINK-35436) Job can't launch when setting the option schema.change.behavior to IGNORE
hk__lrzy created FLINK-35436:
Summary: Job can't launch when setting the option
schema.change.behavior to IGNORE
Key: FLINK-35436
URL: https://issues.apache.org/jira/browse/FLINK-35436
Project: Flink
Issue Type: Improvement
Components: Flink CDC
Reporter: hk__lrzy
Now in the 3.0 pipeline, *SchemaOperator* already was necessary operator in
the Flink DAG, both *PrePartitionOperator* and *DataSinkWriterOperator* have
connection with the *SchemaRegister* according the *schemaEvolutionClient,* but
when we set the option schema.change.behavior to ignore or exception, the
pipeline will add a filter operator instead of the *Schema Operator,* final
cause the job fail.
I think we still need keep the option for the schema.change.behavior to meet
the difference cases, so i advice to move schema.change.behavior to the
*SchemaRegister* to let *SchemaOperator* will be always in the DAG, and let to
*SchemaRegister* decided to apply the schema change or not.{*}{*}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [DISCUSS] FLIP-443: Interruptible watermark processing
Hi Piotrek,
It looks good to me. Thanks for the update!
Best,
Zakelly
On Thu, May 23, 2024 at 7:04 PM Piotr Nowojski
wrote:
> Hi Zakelly,
>
> I've thought about it a bit more, and I think only `#execute()` methods
> make the most sense to be used when implementing operators (and
> interruptible mails), so I will just add `MailOptions` parameters only to
> them. If necessary, we can add more in the future.
>
> I have updated the FLIP. If it looks good to you, I would start a voting
> thread today/tomorrow.
>
> Best,
> Piotrek
>
> czw., 23 maj 2024 o 09:00 Zakelly Lan napisał(a):
>
> > Hi Piotrek,
> >
> > Well, compared to this plan, I prefer your previous one, which is more in
> > line with the intuition for executors' API, by calling `execute`
> directly.
> > Before the variants get too much, I'd suggest we only do minimum change
> for
> > only "interruptible".
> >
> > My original thinking is, doubling each method could result in a scenario
> > where new methods lack callers. But like you said, for the sake of
> > completeness, I could accept the doubling method plan.
> >
> >
> > Thanks & Best,
> > Zakelly
> >
> > On Wed, May 22, 2024 at 5:05 PM Piotr Nowojski
> > wrote:
> >
> > > Hi Zakelly,
> > >
> > > > I suggest not doubling the existing methods. Only providing the
> > following
> > > one is enough
> > >
> > > In that case I would prefer to have a complete set of the methods for
> the
> > > sake of completeness. If the number of variants is/would be getting too
> > > much, we could convert the class into a builder?
> > >
> > >
> > >
> >
> mailboxExecutor.execute(myThrowingRunnable).setInterriptuble().description("bla
> > > %d").arg(42).submit();
> > >
> > > It could be done in both in the future, if we would ever need to add
> even
> > > more methods, or I could do it now. WDYT?
> > >
> > > Best,
> > > Piotrek
> > >
> > > śr., 22 maj 2024 o 08:48 Zakelly Lan
> napisał(a):
> > >
> > > > Hi Piotrek,
> > > >
> > > > `MailOptions` looks good to me. I suggest not doubling the existing
> > > > methods. Only providing the following one is enough:
> > > >
> > > > void execute(
> > > > > MailOptions mailOptions,
> > > > > ThrowingRunnable command,
> > > > > String descriptionFormat,
> > > > > Object... descriptionArgs);
> > > >
> > > >
> > > > WDYT?
> > > >
> > > >
> > > > Best,
> > > > Zakelly
> > > >
> > > >
> > > > On Wed, May 22, 2024 at 12:53 AM Piotr Nowojski <
> pnowoj...@apache.org>
> > > > wrote:
> > > >
> > > > > Hi Zakelly and others,
> > > > >
> > > > > > 1. I'd suggest also providing `isInterruptable()` in `Mail`, and
> > the
> > > > > > continuation mail will return true. The FLIP-425 will leverage
> this
> > > > queue
> > > > > > to execute some state requests, and when the cp arrives, the
> > operator
> > > > may
> > > > > > call `yield()` to drain. It may happen that the continuation mail
> > is
> > > > > called
> > > > > > again in `yield()`. By checking `isInterruptable()`, we can skip
> > this
> > > > > mail
> > > > > > and re-enqueue.
> > > > >
> > > > > Do you have some suggestions on how `isInterruptible` should be
> > > defined?
> > > > > Do we have to double the amount of methods in the
> `MailboxExecutor`,
> > to
> > > > > provide versions of the existing methods, that would enqueue
> > > > > "interruptible"
> > > > > versions of mails? Something like:
> > > > >
> > > > > default void execute(ThrowingRunnable
> > command,
> > > > > String description) {
> > > > > execute(DEFAULT_OPTIONS, command, description);
> > > > > }
> > > > >
> > > > > default void execute(MailOptions options, ThrowingRunnable > > extends
> > > > > Exception> command, String description) {
> > > > > execute(options, command, description, EMPTY_ARGS);
> > > > > }
> > > > >
> > > > > default void execute(
> > > > > ThrowingRunnable command,
> > > > > String descriptionFormat,
> > > > > Object... descriptionArgs) {
> > > > > execute(DEFAULT_OPTIONS, command, descriptionFormat,
> > > > > descriptionArgs);
> > > > > }
> > > > >
> > > > >void execute(
> > > > > MailOptions options,
> > > > > ThrowingRunnable command,
> > > > > String descriptionFormat,
> > > > > Object... descriptionArgs);
> > > > >
> > > > >public static class MailOptions {
> > > > > (...)
> > > > > public MailOptions() {
> > > > > }
> > > > >
> > > > > MailOptions setIsInterruptible() {
> > > > > this.isInterruptible = true;
> > > > > return this;
> > > > > }
> > > > > }
> > > > >
> > > > > And usage would be like this:
> > > > >
> > > > > mailboxExecutor.execute(new MailOptions().setIsInterruptible(), ()
> > -> {
> > > > > foo(); }, "foo");
> > > > >
> > > > > ?
> > > > >
> > > > > Best,
> > > > > Piotrek
> > > > >
> > > > > czw., 16 maj 2024 o 11:26 Rui Fan <1996fan...@gmail.com>
> napisał(a):
> > > > >
> > > > > > Hi P
[VOTE] FLIP-443: Interruptible watermark processing
Hi all, After reaching what looks like a consensus in the discussion thread [1], I would like to put FLIP-443 [2] to the vote. The vote will be open for at least 72 hours unless there is an objection or insufficient votes. [1] https://lists.apache.org/thread/flxm7rphvfgqdn2gq2z0bb7kl007olpz [2] https://cwiki.apache.org/confluence/x/qgn9EQ Bets, Piotrek
Re: [DISCUSSION] FLIP-457: Improve Table/SQL Configuration for Flink 2.0
Hi Leonard, Thank you for the feedback and the improvement. If there are no further comments or concerns, I would like to initiate a vote on this. Best, Jane On Wed, May 22, 2024 at 9:24 PM Leonard Xu wrote: > Thanks Jane for the refine work, +1 from my side. > I adjusted the table format of FLIP so that it can display all content in > one page. > > Best, > Leonard > > > > 2024年5月22日 下午3:42，Jane Chan 写道： > > > > Hi Lincoln, > > > > Thanks for your suggestion. I've reviewed the comments from the previous > PR > > review[1], and the agreement at the time was that any configuration > options > > not included in ExecutionConfigOptions and OptimizerConfigOptions should > > have the Experimental annotation explicitly added. Since this annotation > > has been relatively stable from 1.9.0 until now, you make a valid point, > > and we can elevate it to the PublicEvolving level. > > > > Please let me know if you have any questions. > > > > [1] https://github.com/apache/flink/pull/8980 > > > > Best, > > Jane > > > > On Tue, May 21, 2024 at 10:25 PM Lincoln Lee > wrote: > > > >> Hi Jane, > >> > >> Thanks for the updates! > >> > >> Just one small comment on the options in IncrementalAggregateRule > >> & RelNodeBlock, should we also change the API level from Experimental > >> to PublicEvolving? > >> > >> > >> Best, > >> Lincoln Lee > >> > >> > >> Jane Chan 于2024年5月21日周二 16:41写道： > >> > >>> Hi all, > >>> > >>> Thanks for your valuable feedback! > >>> > >>> To @Xuannan > >>> > >>> For options to be moved to another module/package, I think we have to > mark the old option deprecated in 1.20 for it to be removed in 2.0, > according to the API compatibility guarantees[1]. We can introduce the > new option in 1.20 with the same option key in the intended class. > >>> > >>> > >>> Good point, fixed. > >>> > >>> To @Lincoln and @Benchao > >>> > >>> Thanks for sharing the insights into the historical context of which I > >> was > >>> unaware. I've reorganized the sheet. > >>> > >>> 3. Regarding WindowEmitStrategy, IIUC it is currently unsupported on > TVF > window, so it's recommended to keep it untouched for now and follow up > >> in > FLINK-29692 > >>> > >>> > >>> How to tackle the configuration is up to whether to remove the legacy > >>> window aggregate in 2.0, and I've updated the FLIP to leverage this > part > >> to > >>> FLINK-29692. > >>> > >>> Please let me know if that answers your questions or if you have other > >>> comments. > >>> > >>> Best, > >>> Jane > >>> > >>> > >>> On Mon, May 20, 2024 at 1:52 PM Ron Liu wrote: > >>> > Hi, Lincoln > > > 2. Regarding the options in HashAggCodeGenerator, since this new > >>> feature > has gone > through a couple of release cycles and could be considered for > PublicEvolving now, > cc @Ron Liu WDYT? > > Thanks for cc'ing me, +1 for public these options now. > > Best, > Ron > > Benchao Li 于2024年5月20日周一 13:08写道： > > > I agree with Lincoln about the experimental features. > > > > Some of these configurations do not even have proper implementation, > > take 'table.exec.range-sort.enabled' as an example, there was a > > discussion[1] about it before. > > > > [1] https://lists.apache.org/thread/q5h3obx36pf9po28r0jzmwnmvtyjmwdr > > > > Lincoln Lee 于2024年5月20日周一 12:01写道： > >> > >> Hi Jane, > >> > >> Thanks for the proposal! > >> > >> +1 for the changes except for these annotated as experimental ones. > >> > >> For the options annotated as experimental, > >> > >> +1 for the moving of IncrementalAggregateRule & RelNodeBlock. > >> > >> For the rest of the options, there are some suggestions: > >> > >> 1. for the batch related parameters, it's recommended to either > >>> delete > >> them (leaving the necessary defaults value in place) or leave them > >> as > > they > >> are. Including: > >> FlinkRelMdRowCount > >> FlinkRexUtil > >> BatchPhysicalSortRule > >> JoinDeriveNullFilterRule > >> BatchPhysicalJoinRuleBase > >> BatchPhysicalSortMergeJoinRule > >> > >> What I understand about the history of these options is that they > >>> were > > once > >> used for fine > >> tuning for tpc testing, and the current flink planner no longer > >>> relies > on > >> these internal > >> options when testing tpc[1]. In addition, these options are too > >>> obscure > > for > >> SQL users, > >> and some of them are actually magic numbers. > >> > >> 2. Regarding the options in HashAggCodeGenerator, since this new > feature > >> has gone > >> through a couple of release cycles and could be considered for > >> PublicEvolving now, > >> cc @Ron Liu WDYT? > >> > >> 3. Regarding WindowEmitStrategy, IIUC it is currently unsupported > >> on > TVF > >> window, so > >> it's recommended to
[jira] [Created] (FLINK-35437) BlockStatementGrouper uses lots of memory
Dawid Wysakowicz created FLINK-35437:
Summary: BlockStatementGrouper uses lots of memory
Key: FLINK-35437
URL: https://issues.apache.org/jira/browse/FLINK-35437
Project: Flink
Issue Type: Improvement
Components: Table SQL / Runtime
Affects Versions: 1.19.0
Reporter: Dawid Wysakowicz
Assignee: Dawid Wysakowicz
Fix For: 1.20.0
For deeply nested {{if else}} statements {{BlockStatementGrouper}} uses loads
of memory and fails with OOM quickly.
When running JMs with around 400mb a query like:
```
select case when orderid = 0 then 1 when orderid = 1 then 2 when orderid
= 2 then 3 when orderid = 3 then 4 when orderid = 4 then 5 when orderid = 5
then
6 when orderid = 6 then 7 when orderid = 7 then 8 when orderid = 8 then 9
when
orderid = 9 then 10 when orderid = 10 then 11 when orderid = 11 then 12
when orderid
= 12 then 13 when orderid = 13 then 14 when orderid = 14 then 15 when
orderid
= 15 then 16 when orderid = 16 then 17 when orderid = 17 then 18 when
orderid
= 18 then 19 when orderid = 19 then 20 when orderid = 20 then 21 when
orderid
= 21 then 22 when orderid = 22 then 23 when orderid = 23 then 24 when
orderid
= 24 then 25 when orderid = 25 then 26 when orderid = 26 then 27 when
orderid
= 27 then 28 when orderid = 28 then 29 when orderid = 29 then 30 when
orderid
= 30 then 31 when orderid = 31 then 32 when orderid = 32 then 33 when
orderid
= 33 then 34 when orderid = 34 then 35 when orderid = 35 then 36 when
orderid
= 36 then 37 when orderid = 37 then 38 when orderid = 38 then 39 when
orderid
= 39 then 40 when orderid = 40 then 41 when orderid = 41 then 42 when
orderid
= 42 then 43 when orderid = 43 then 44 when orderid = 44 then 45 when
orderid
= 45 then 46 when orderid = 46 then 47 when orderid = 47 then 48 when
orderid
= 48 then 49 when orderid = 49 then 50 when orderid = 50 then 51 when
orderid
= 51 then 52 when orderid = 52 then 53 when orderid = 53 then 54 when
orderid
= 54 then 55 when orderid = 55 then 56 when orderid = 56 then 57 when
orderid
= 57 then 58 when orderid = 58 then 59 when orderid = 59 then 60 when
orderid
= 60 then 61 when orderid = 61 then 62 when orderid = 62 then 63 when
orderid
= 63 then 64 when orderid = 64 then 65 when orderid = 65 then 66 when
orderid
= 66 then 67 when orderid = 67 then 68 when orderid = 68 then 69 when
orderid
= 69 then 70 when orderid = 70 then 71 when orderid = 71 then 72 when
orderid
= 72 then 73 when orderid = 73 then 74 when orderid = 74 then 75 when
orderid
= 75 then 76 when orderid = 76 then 77 when orderid = 77 then 78 when
orderid
= 78 then 79 when orderid = 79 then 80 when orderid = 80 then 81 when
orderid
= 81 then 82 when orderid = 82 then 83 when orderid = 83 then 84 when
orderid
= 84 then 85 when orderid = 85 then 86 when orderid = 86 then 87 when
orderid
= 87 then 88 when orderid = 88 then 89 when orderid = 89 then 90 when
orderid
= 90 then 91 when orderid = 91 then 92 when orderid = 92 then 93 when
orderid
= 93 then 94 when orderid = 94 then 95 when orderid = 95 then 96 when
orderid
= 96 then 97 when orderid = 97 then 98 when orderid = 98 then 99 when
orderid
= 99 then 100 when orderid = 100 then 101 when orderid = 101 then 102 when
orderid
= 102 then 103 when orderid = 103 then 104 when orderid = 104 then 105 when
orderid
= 105 then 106 when orderid = 106 then 107 when orderid = 107 then 108 when
orderid
= 108 then 109 when orderid = 109 then 110 when orderid = 110 then 111 when
orderid
= 111 then 112 when orderid = 112 then 113 when orderid = 113 then 114 when
orderid
= 114 then 115 when orderid = 115 then 116 when orderid = 116 then 117 when
orderid
= 117 then 118 when orderid = 118 then 119 when orderid = 119 then 120 when
orderid
= 120 then 121 when orderid = 121 then 122 when orderid = 122 then 123 when
orderid
= 123 then 124 when orderid = 124 then 125 when orderid = 125 then 126 when
orderid
= 126 then 127 when orderid = 127 then 128 when orderid = 128 then 129 when
orderid
= 129 then 130 when orderid = 130 then 131 when orderid = 131 then 132 when
orderid
= 132 then 133 when orderid = 133 then 134 when orderid = 134 then 135 when
orderid
= 135 then 136 when orderid = 136 then 137 when orderid = 137 then 138 when
orderid
= 138 then 139 when orderid = 139 then 140 when orderid = 140 then 141 when
orderid
= 141 then 142 when orderid = 142 then 143 when orderid = 143 then 144 when
orderid
= 144 then 145 when orderid = 145 then 146 when orderid = 146 then 147 when
orderid
= 147 then 148 when orderid = 148 then 149 when orderid = 149 then 150 when
orderid
= 150 then 151 when orderid = 151 then 152 when orderid = 152 then 153 when
ord
[jira] [Created] (FLINK-35438) SourceCoordinatorTest.testErrorThrownFromSplitEnumerator fails on wrong error
Ryan Skraba created FLINK-35438:
---
Summary: SourceCoordinatorTest.testErrorThrownFromSplitEnumerator
fails on wrong error
Key: FLINK-35438
URL: https://issues.apache.org/jira/browse/FLINK-35438
Project: Flink
Issue Type: Bug
Affects Versions: 1.18.2
Reporter: Ryan Skraba
* 1.18 Java 11 / Test (module: core)
https://github.com/apache/flink/actions/runs/9201159842/job/25309197630#step:10:7375
We expect to see an artificial {{Error("Test Error")}} being reported in the
test as the cause of a job failure, but the reported job failure is null:
{code}
Error: 02:32:31 02:32:31.950 [ERROR] Tests run: 18, Failures: 1, Errors: 0,
Skipped: 0, Time elapsed: 0.187 s <<< FAILURE! - in
org.apache.flink.runtime.source.coordinator.SourceCoordinatorTest
Error: 02:32:31 02:32:31.950 [ERROR]
org.apache.flink.runtime.source.coordinator.SourceCoordinatorTest.testErrorThrownFromSplitEnumerator
Time elapsed: 0.01 s <<< FAILURE!
May 23 02:32:31 org.opentest4j.AssertionFailedError:
May 23 02:32:31
May 23 02:32:31 expected:
May 23 02:32:31 java.lang.Error: Test Error
May 23 02:32:31 at
org.apache.flink.runtime.source.coordinator.SourceCoordinatorTest.testErrorThrownFromSplitEnumerator(SourceCoordinatorTest.java:296)
May 23 02:32:31 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
May 23 02:32:31 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
May 23 02:32:31 ...(57 remaining lines not displayed - this can be
changed with Assertions.setMaxStackTraceElementsDisplayed)
May 23 02:32:31 but was:
May 23 02:32:31 null
May 23 02:32:31 at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
May 23 02:32:31 at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
May 23 02:32:31 at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
May 23 02:32:31 at
org.apache.flink.runtime.source.coordinator.SourceCoordinatorTest.testErrorThrownFromSplitEnumerator(SourceCoordinatorTest.java:322)
May 23 02:32:31 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
May 23 02:32:31 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
May 23 02:32:31 at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
May 23 02:32:31 at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
May 23 02:32:31 at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
May 23 02:32:31 at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
May 23 02:32:31 at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
May 23 02:32:31 at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
May 23 02:32:31 at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
{code}
This looks like it's a multithreading error with the test
{{MockOperatorCoordinatorContext}}, perhaps where {{isJobFailure}} can return
true before the reason has been populated. I couldn't reproduce it after
running it 1M times.
--
This message was sent by At
[jira] [Created] (FLINK-35439) Python Support for AvroSchemaConverter
Greg Wills created FLINK-35439: -- Summary: Python Support for AvroSchemaConverter Key: FLINK-35439 URL: https://issues.apache.org/jira/browse/FLINK-35439 Project: Flink Issue Type: Improvement Components: API / Python Affects Versions: 1.18.1, 1.17.2 Reporter: Greg Wills The java class org.apache.flink.formats.avro.typeutils.AvroSchemaConverter is not integrated into the apache-flink Python library (pyflink). My goal is to dynamically create a Pyflink table schema from an avro schema, but without a Python interface via py4j do so, that task is difficult. Especially for the Table API, this would improve schema management and evolution practices. Currently, the responsibility is on the user to statically create the table schema (used as the Avro reader schema). Schema updates can cause this static reader schema that is generated from the table schema to be incompatible with the writer schema (when consuming/deserializing). This is the case specifically for the format avro-confluent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Good point, Xintong, I incorporated this item into the FLIP. Best, Alex On Wed, 22 May 2024 at 10:37, Xintong Song wrote: > Thanks, Alex. > > I see one task that needs to be done once the FLIP is approved, which I'd > suggest to also mention in the: To explain the LTS policy to users on > website / documentation (because FLIP is developer-facing) before / upon > releasing 1.20. > > Other than that, the FLIP LGTM. > > Best, > > Xintong > > > > On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov < > alexander.fedu...@gmail.com> wrote: > > > Hi everyone, > > > > let's finalize this discussion. As Martijn suggested, I summarized this > > thread into a FLIP [1]. Please take a look and let me know if there’s > > anything important that I might have missed. > > > > Best, > > Alex > > > > [1] https://cwiki.apache.org/confluence/x/BApeEg > > > > > > On Tue, 23 Jan 2024 at 03:30, Rui Fan <1996fan...@gmail.com> wrote: > > > > > Thanks Martijn for the feedback! > > > > > > Sounds make sense to me! And I don't have strong opinion that allow > > > backporting new features to 1.x. > > > > > > Best, > > > Rui > > > > > > On Mon, Jan 22, 2024 at 8:56 PM Martijn Visser < > martijnvis...@apache.org > > > > > > wrote: > > > > > > > Hi Rui, > > > > > > > > I don't think that we should allow backporting of new features from > > > > the first minor version of 2.x to 1.x. If a user doesn't yet want to > > > > upgrade to 2.0, I think that's fine since we'll have a LTS for 1.x. > If > > > > a newer feature becomes available in 2.x that's interesting for the > > > > user, the user at that point can decide if they want to do the > > > > migration. It's always a case-by-case tradeoff of effort vs benefits, > > > > and I think with a LTS version that has bug fixes only we provide the > > > > users with assurance that existing bugs can get fixed, and that they > > > > can decide for themselves when they want to migrate to a newer > version > > > > with better/newer features. > > > > > > > > Best regards, > > > > > > > > Martijn > > > > > > > > On Thu, Jan 11, 2024 at 3:50 AM Rui Fan <1996fan...@gmail.com> > wrote: > > > > > > > > > > Thanks everyone for discussing this topic! > > > > > > > > > > My question is could we make a trade-off between Flink users > > > > > and Flink maintainers? > > > > > > > > > > 1. From the perspective of a Flink maintainer > > > > > > > > > > I strongly agree with Martin's point of view, such as: > > > > > > > > > > - Allowing backporting of new features to Flink 1.x will result in > > > users > > > > > delaying the upgrade. > > > > > - New features will also introduce new bugs, meaning that > maintainers > > > > will > > > > > have to spend time on two release versions. > > > > > > > > > > Considering the simplicity of maintenance, don't backport > > > > > new features to Flink 1.x is fine. > > > > > > > > > > 2. From the perspective of a flink user > > > > > > > > > > In the first version Flink 2.x, flink will remove a lot of > > > > > deprecated api, and introduce some features. > > > > > > > > > > It's a new major version, major version changes are much > > > > > greater than minor version and patch version. Big changes > > > > > may introduce more bugs, so I guess that a large number > > > > > of Flink users will not use the first version of 2.x in the > > > > > production environment. Maybe they will wait for the second > > > > > minor version of 2.x. > > > > > > > > > > So, I was wondering whether we allow backport new features > > > > > from the first minor version of 2.x to 1.x? > > > > > > > > > > It means, we allow backport new features of 2.0.0 to 1.21. > > > > > And 1.21.x is similar to 2.0.x, their features are same, but > > > > > 2.0.x removes deprecated apis. After 2.0.0 is released, > > > > > all new features in 2.1.x and above are only available in 2.x. > > > > > > > > > > Looking forward to your opinions~ > > > > > > > > > > Best, > > > > > Rui > > > > > > > > > > On Wed, Jan 10, 2024 at 9:39 PM Martijn Visser < > > > martijnvis...@apache.org > > > > > > > > > > wrote: > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > I saw that I missed replying to this topic. I do think that > Xintong > > > > > > touched on an important topic when he mentioned that we should > > define > > > > > > what an LTS version means. From my point of view, I would state > > that > > > > > > an LTS version for Apache Flink means that bug fixes only will be > > > made > > > > > > available for a longer period of time. I think that, combined > with > > > > > > what you called option 1 (a clear end-of-life date) is the best > > > > > > option. > > > > > > > > > > > > Flink 2.0 will give us primarily the ability to remove a lot of > > > > > > deprecated APIs, especially with Flink's deprecation strategy. I > > > > > > expect that the majority of users will have an easy migration > path > > > > > > from a Flink 1.x to a Flink 2.0, if you're currently not using a > > > > > > deprecated API and are a Java user. >
[jira] [Created] (FLINK-35440) unable to connect tableau to jdbc flink url using flink sql driver
Zach created FLINK-35440:
Summary: unable to connect tableau to jdbc flink url using flink
sql driver
Key: FLINK-35440
URL: https://issues.apache.org/jira/browse/FLINK-35440
Project: Flink
Issue Type: Bug
Components: Table SQL / JDBC
Affects Versions: 1.19.0, 1.20.0
Reporter: Zach
Tableau 2023.1 using
[https://repo.maven.apache.org/maven2/org/apache/flink/flink-sql-jdbc-driver-bundle/]
version 1.19.0 yields the following error when a connection is established to
a local flink sql cluster using the uri
{{{}jdbc:{}}}{{{}[flink://localhost:8083]{}}}
{{{"ts":"2024-05-23T14:21:05.858","pid":12172,"tid":"6a70","sev":"error","req":"-","sess":"-","site":"-","user":"-","k":"jdbc-error","e":\{"excp-error-code":"0xFAB9A2C5","excp-source":"NeedsClassification","excp-status-code":"UNKNOWN"},"v":\{"context":"GrpcProtocolProxy::IsConnected
(D:\\tc\\work\\t231\\g_pc\\modules\\connectors\\tabmixins\\main\\db\\GrpcProtocolProxy.cpp:456)","driver-name":"org.apache.flink.table.jdbc.FlinkDriver","driver-version":"1.19.0","error-code":"0","error-messages":["FlinkConnection#isValid
is not supported
yet."],"grpc-status-code":"2","protocol-id":3,"sql-state":"0"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[VOTE] FLIP-457: Improve Table/SQL Configuration for Flink 2.0
Hi all, I'd like to start a vote on FLIP-457[1] after reaching a consensus through the discussion thread[2]. The vote will be open for at least 72 hours unless there is an objection or insufficient votes. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=307136992 [2] https://lists.apache.org/thread/1sthbv6q00sq52pp04n2p26d70w4fqj1 Best, Jane
Re: [VOTE] FLIP-443: Interruptible watermark processing
+1 (binding) Best, Zakelly On Thu, May 23, 2024 at 8:21 PM Piotr Nowojski wrote: > Hi all, > > After reaching what looks like a consensus in the discussion thread [1], I > would like to put FLIP-443 [2] to the vote. > > The vote will be open for at least 72 hours unless there is an objection or > insufficient votes. > > [1] https://lists.apache.org/thread/flxm7rphvfgqdn2gq2z0bb7kl007olpz > [2] https://cwiki.apache.org/confluence/x/qgn9EQ > > Bets, > Piotrek >
[jira] [Created] (FLINK-35441) Add CDC upgrade compatibility tests
yux created FLINK-35441: --- Summary: Add CDC upgrade compatibility tests Key: FLINK-35441 URL: https://issues.apache.org/jira/browse/FLINK-35441 Project: Flink Issue Type: Bug Components: Flink CDC Reporter: yux Currently, there's no test cases to guarantee checkpoint state compatibility between different CDC versions like Flink's SerializerUpgradeTestBase. Adding it should help CDC users upgrading version with more confidence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FLINK-35442) Kafka Pipeline Sink may distribute the same key to different partitions after modify parallelism
LvYanquan created FLINK-35442: - Summary: Kafka Pipeline Sink may distribute the same key to different partitions after modify parallelism Key: FLINK-35442 URL: https://issues.apache.org/jira/browse/FLINK-35442 Project: Flink Issue Type: Improvement Components: Flink CDC Affects Versions: cdc-3.2.0 Reporter: LvYanquan Fix For: cdc-3.2.0 Currently, Kafka Pipeline Sink partition events by parallelInstanceId % partitions.length，this is because the previous partition operator has already shuffled events by key. However, If the parallelism of the task is modified and restarted, data with the same key before and after the task may be in different partitions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] FLIP-443: Interruptible watermark processing
Thanks for driving this! +1 (binding) Best, Yanfei Zakelly Lan 于2024年5月24日周五 10:13写道： > > +1 (binding) > > Best, > Zakelly > > On Thu, May 23, 2024 at 8:21 PM Piotr Nowojski wrote: > > > Hi all, > > > > After reaching what looks like a consensus in the discussion thread [1], I > > would like to put FLIP-443 [2] to the vote. > > > > The vote will be open for at least 72 hours unless there is an objection or > > insufficient votes. > > > > [1] https://lists.apache.org/thread/flxm7rphvfgqdn2gq2z0bb7kl007olpz > > [2] https://cwiki.apache.org/confluence/x/qgn9EQ > > > > Bets, > > Piotrek > >
Re: Discussion: Condition field in the CR status
Thanks David for the feedback. Yes you are right. We can provide meaningful information in reason rather than provide it as "Ready". Message will have more detailed information . Also updated document on how to handle multiple conditions in status. Thanks Lajith On Mon, May 13, 2024 at 4:00 PM David Radley wrote: > Hi Lajith, > This idea for a Flip is a good addition, which I support. > > As discussed: > > These conditions populate a status field in the K8s UI – Openshift in our > case. Currently the status does not contain any information. With the > conditions present, the status will be populated with meaningful > information on the UI; which means the readiness is explicitly shown on the > UI improving the users experience . > > One other observation, in your example : > > reason: Ready > > status: 'True' > > type: Ready > > > > Could reason be something more granular to give more information about > Ready status, maybe rolledback, deployed or stable? > > We also talked of whether there are any use cases would be beneficial, at > this time we don’t think so – but you said you have a look at this, > >Kind regards, David, > > > From: Lajith Koova > Date: Monday, 13 May 2024 at 10:29 > To: dev@flink.apache.org > Subject: [EXTERNAL] Re: Discussion: Condition field in the CR status > Thanks for the feedback Jeyhun. > > Regarding Will the usage of Conditions be enabled by default? Or will there > be any > disadvantages for Flink users . Yes the conditions will be enabled by > default for the CR. > > You are right , when there are multiple conditions of the same type, > approach is we will override the old condition with new conditions only if > conditions status and messages are the same. If they are different , we > will add to existing conditions. > > Thanks > Lajith > > On Fri, May 3, 2024 at 8:05 PM Jeyhun Karimov > wrote: > > > Hi Lajith, > > > > Thanks a lot for driving this FLIP. Please find my comments below: > > > > - I echo Gyula that including some examples and further explanations > might > > ease reader's work. With the current version, the FLIP is a bit hard to > > follow. > > > > - Will the usage of Conditions be enabled by default? Or will there be > any > > disadvantages for Flink users? > > > > If Conditions with the same type already exist in the Status Conditions > > > list, then replace the existing condition with the same type if the > > > Condition status and message are different. > > > > - Do you think we should have clear rules about handling rules for how > > these Conditions should be managed, especially when multiple Conditions > of > > the same type are present? > > For example, resource has multiple causes for the same condition (e.g., > > Error due to network and Error due to I/O). Then, overriding the old > > condition with the new one is not the best approach no? > > Please correct me if I misunderstood. > > > > Regards, > > Jeyhun > > > > On Fri, May 3, 2024 at 8:53 AM Gyula Fóra wrote: > > > > > Hi Lajith! > > > > > > Can you please include some examples in the document to help reviewers? > > > Just some examples with the status and the proposed conditions. > > > > > > Cheers, > > > Gyula > > > > > > On Wed, May 1, 2024 at 9:06 AM Lajith Koova > wrote: > > > > > > > Hello, > > > > > > > > > > > > Starting discussion thread here to discuss a proposal to add > Conditions > > > > field in the CR status of Flink Deployment and FlinkSessionJob. > > > > > > > > > > > > Here is the google doc with details. Please provide your > > thoughts/inputs. > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/12wlJCL_Vq2KZnABzK7OR7gAd1jZMmo0MxgXQXqtWODs/edit?usp=sharing > > > > > > > > > > > > Thanks > > > > Lajith > > > > > > > > > > > Unless otherwise stated above: > > IBM United Kingdom Limited > Registered in England and Wales with number 741598 > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU >
Re: [VOTE] FLIP-457: Improve Table/SQL Configuration for Flink 2.0
+1(binding) Best, Lincoln Lee Jane Chan 于2024年5月24日周五 09:52写道： > Hi all, > > I'd like to start a vote on FLIP-457[1] after reaching a consensus through > the discussion thread[2]. > > The vote will be open for at least 72 hours unless there is an objection or > insufficient votes. > > > [1] > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=307136992 > [2] https://lists.apache.org/thread/1sthbv6q00sq52pp04n2p26d70w4fqj1 > > Best, > Jane >
Re: [VOTE] FLIP-443: Interruptible watermark processing
+1(binding) Best, Rui On Fri, May 24, 2024 at 12:01 PM Yanfei Lei wrote: > Thanks for driving this! > > +1 (binding) > > Best, > Yanfei > > Zakelly Lan 于2024年5月24日周五 10:13写道： > > > > > +1 (binding) > > > > Best, > > Zakelly > > > > On Thu, May 23, 2024 at 8:21 PM Piotr Nowojski > wrote: > > > > > Hi all, > > > > > > After reaching what looks like a consensus in the discussion thread > [1], I > > > would like to put FLIP-443 [2] to the vote. > > > > > > The vote will be open for at least 72 hours unless there is an > objection or > > > insufficient votes. > > > > > > [1] https://lists.apache.org/thread/flxm7rphvfgqdn2gq2z0bb7kl007olpz > > > [2] https://cwiki.apache.org/confluence/x/qgn9EQ > > > > > > Bets, > > > Piotrek > > > >
Re: [VOTE] FLIP-457: Improve Table/SQL Configuration for Flink 2.0
+1(binding) Best regards, Weijie Lincoln Lee 于2024年5月24日周五 12:20写道： > +1(binding) > > Best, > Lincoln Lee > > > Jane Chan 于2024年5月24日周五 09:52写道： > > > Hi all, > > > > I'd like to start a vote on FLIP-457[1] after reaching a consensus > through > > the discussion thread[2]. > > > > The vote will be open for at least 72 hours unless there is an objection > or > > insufficient votes. > > > > > > [1] > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=307136992 > > [2] https://lists.apache.org/thread/1sthbv6q00sq52pp04n2p26d70w4fqj1 > > > > Best, > > Jane > > >
Re: [VOTE] FLIP-443: Interruptible watermark processing
+1(binding) Thanks for driving this! Best regards, Weijie Rui Fan <1996fan...@gmail.com> 于2024年5月24日周五 13:03写道： > +1(binding) > > Best, > Rui > > On Fri, May 24, 2024 at 12:01 PM Yanfei Lei wrote: > > > Thanks for driving this! > > > > +1 (binding) > > > > Best, > > Yanfei > > > > Zakelly Lan 于2024年5月24日周五 10:13写道： > > > > > > > > +1 (binding) > > > > > > Best, > > > Zakelly > > > > > > On Thu, May 23, 2024 at 8:21 PM Piotr Nowojski > > wrote: > > > > > > > Hi all, > > > > > > > > After reaching what looks like a consensus in the discussion thread > > [1], I > > > > would like to put FLIP-443 [2] to the vote. > > > > > > > > The vote will be open for at least 72 hours unless there is an > > objection or > > > > insufficient votes. > > > > > > > > [1] https://lists.apache.org/thread/flxm7rphvfgqdn2gq2z0bb7kl007olpz > > > > [2] https://cwiki.apache.org/confluence/x/qgn9EQ > > > > > > > > Bets, > > > > Piotrek > > > > > > >
[jira] [Created] (FLINK-35443) ChangelogLocalRecoveryITCase failed fatally with 239 exit code
Weijie Guo created FLINK-35443: -- Summary: ChangelogLocalRecoveryITCase failed fatally with 239 exit code Key: FLINK-35443 URL: https://issues.apache.org/jira/browse/FLINK-35443 Project: Flink Issue Type: Bug Components: Build System / CI Affects Versions: 1.20.0 Reporter: Weijie Guo -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] FLIP-457: Improve Table/SQL Configuration for Flink 2.0
+1 Best, Leonard > 2024年5月24日 下午1:27，weijie guo 写道： > > +1(binding) > > Best regards, > > Weijie > > > Lincoln Lee 于2024年5月24日周五 12:20写道： > >> +1(binding) >> >> Best, >> Lincoln Lee >> >> >> Jane Chan 于2024年5月24日周五 09:52写道： >> >>> Hi all, >>> >>> I'd like to start a vote on FLIP-457[1] after reaching a consensus >> through >>> the discussion thread[2]. >>> >>> The vote will be open for at least 72 hours unless there is an objection >> or >>> insufficient votes. >>> >>> >>> [1] >>> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=307136992 >>> [2] https://lists.apache.org/thread/1sthbv6q00sq52pp04n2p26d70w4fqj1 >>> >>> Best, >>> Jane >>> >>
Re: [VOTE] FLIP-457: Improve Table/SQL Configuration for Flink 2.0
+1(binding) Best, Rui On Fri, May 24, 2024 at 1:45 PM Leonard Xu wrote: > +1 > > Best, > Leonard > > > 2024年5月24日 下午1:27，weijie guo 写道： > > > > +1(binding) > > > > Best regards, > > > > Weijie > > > > > > Lincoln Lee 于2024年5月24日周五 12:20写道： > > > >> +1(binding) > >> > >> Best, > >> Lincoln Lee > >> > >> > >> Jane Chan 于2024年5月24日周五 09:52写道： > >> > >>> Hi all, > >>> > >>> I'd like to start a vote on FLIP-457[1] after reaching a consensus > >> through > >>> the discussion thread[2]. > >>> > >>> The vote will be open for at least 72 hours unless there is an > objection > >> or > >>> insufficient votes. > >>> > >>> > >>> [1] > >>> > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=307136992 > >>> [2] https://lists.apache.org/thread/1sthbv6q00sq52pp04n2p26d70w4fqj1 > >>> > >>> Best, > >>> Jane > >>> > >> > >
