Re: [VOTE] Release 1.12.2, release candidate #1

[Yu Li]

+1 (binding)

- Checked the diff between 1.12.1 and 1.12.2: OK (
https://github.com/apache/flink/compare/release-1.12.1...release-1.12.2-rc1)
  - jackson version has been bumped to 2.10.5.1 through FLINK-21020 and all
NOTICE files updated correctly
  - beanutils version has been bumped to 1.9.4 through FLINK-21123 and all
NOTICE files updated correctly
  - testcontainer version has been bumped to 1.15.1 through FLINK-21277 and
no NOTICE files impact
  - japicmp version has been bumped to 1.12.1 and no NOTICE files impact
- Checked release notes: OK
- Checked sums and signatures: OK
- Maven clean install from source: OK
- Checked the jars in the staging repo: OK
- Checked binary archive: OK
- Approved the website updates (left some notes in PR)

Thanks a lot for putting the RC together!

Best Regards,
Yu


On Sat, 20 Feb 2021 at 12:59, Xintong Song  wrote:

> +1 (non-binding)
>
> - verified checksums & signatures
> - reviewed website PR
> - build from source
> - run example jobs
>   - standalone session & yarn per-job
>   - jobs work as expected
>   - ui & logs look good
>
> Thank you~
>
> Xintong Song
>
>
>
> On Fri, Feb 19, 2021 at 9:59 PM Piotr Nowojski 
> wrote:
>
> > Hi,
> >
> > Thanks for preparing this release candidate.
> >
> > +1 from my side
> >
> > 1. I was monitoring recent builds for Unaligned Checkpoint issues and I
> can
> > confirm that it seems we don't have any failures in the last couple of
> > weeks.
> > 2. There are no tickets with fix version set to 1.12.2. There are two
> > blocker bugs for 1.12.3, but they are still quite far from being merged
> and
> > they shouldn't block the 1.12.2 release, as they have been present in the
> > past release already.
> > 3. I double confirmed that there are no dependency changes between 1.12.1
> > and 1.12.2-RC1, apart of the upgrade of `commons-beanutils` from 1.9.3 to
> > 1.9.4, which had and maintained Apache 2.0 license.
> >
> > Piotrek
> >
> > pt., 19 lut 2021 o 10:24 Yuan Mei  napisał(a):
> >
> > > Hey Roman,
> > >
> > > Thanks for preparing RC1!
> > >
> > > +1 from my side.
> > >
> > > 1. Run-through UnalignedCheckpointITCase for 800+ rounds to make
> > > sure UnalignedCheckpoint is stable
> > > 2. Verified Checksums and GPG Signature
> > > 3. Verified that the source archives do not contain any binaries
> > > 4. Successfully Built the source with Maven, started a local Flink
> > cluster,
> > > and ran the streaming WordCount example with WebMonitor without
> > suspicious
> > > output
> > > 5. Successfully ran the streaming WordCount example with the binary
> > release
> > > as well
> > > 6. Checked for source and binary release to make sure both an Apache
> > > License file and a NOTICE file are included
> > > 7. Manually check all pom file changes since the last release (Flink
> > > 1.12.1); no obvious license problem for me (Need someone to double
> > confirm
> > > this).
> > >
> > > Best
> > > Yuan
> > >
> > > On Wed, Feb 17, 2021 at 3:25 AM Roman Khachatryan 
> > > wrote:
> > >
> > > > Hi everyone,
> > > > Please review and vote on the release candidate #1 for the version
> > > 1.12.2,
> > > > 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],
> > > > * the official Apache source release and binary convenience releases
> to
> > > be
> > > > deployed to dist.apache.org [2], which are signed with the key with
> > > > fingerprint 0D545F264D2DFDEBFD4E038F97B4625E2FCF517C [3],
> > > > * all artifacts to be deployed to the Maven Central Repository [4],
> > > > * source code tag "release-1.12.2-rc1" [5],
> > > > * website pull request listing the new release and adding
> announcement
> > > > blog post [6].
> > > >
> > > > The vote will be open for at least 72 hours. It is adopted by
> majority
> > > > approval, with at least 3 PMC affirmative votes.
> > > >
> > > >
> > > > Regards,
> > > > Roman
> > > >
> > > > [1]
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12349502=12315522
> > > > [2] https://dist.apache.org/repos/dist/dev/flink/flink-1.12.2-rc1/
> > > > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> > > > [4]
> > > >
> > https://repository.apache.org/content/repositories/orgapacheflink-1413/
> > > > [5] https://github.com/apache/flink/releases/tag/release-1.12.2-rc1
> > > > [6] https://github.com/apache/flink-web/pull/418
> > > >
> > >
> >
>

Re: 来自张亚凯的邮件

[Xintong Song]

Hi,

Welcome to the community!
You don't need a contributor permission to contribute to Apache Flink.
Simply find a JIRA ticket you'd like to work on and ask a committer to
assign you to the ticket.
You may find more details in the contribution guidelines [1].

[1] https://flink.apache.org/contributing/how-to-contribute.html



Thank you~

Xintong Song



On Sat, Feb 20, 2021 at 1:36 PM 张亚凯 <18337190...@163.com> wrote:

> |
> Hi Guys,
>
> I want to contribute to Apache Flink.
> Would you please give me the permission as a contributor?
> My JIRA ID is Ethan-zhang.
> |

来自张亚凯的邮件

[张亚凯]

|
Hi Guys,

I want to contribute to Apache Flink.
Would you please give me the permission as a contributor?
My JIRA ID is Ethan-zhang.
|

[jira] [Created] (FLINK-21423) PartitionNotFoundException when job run on 2 taskmanager with standalone cluster mode

[Sheng Zhang (Jira)]

Sheng Zhang created FLINK-21423:
---

 Summary: PartitionNotFoundException when job run on 2 taskmanager 
with standalone cluster mode
 Key: FLINK-21423
 URL: https://issues.apache.org/jira/browse/FLINK-21423
 Project: Flink
  Issue Type: Bug
  Components: Runtime / Network, Runtime / Task
Affects Versions: 1.12.1
 Environment: flink1.12

hadoop3.3.0

jdk15.0.2

zookeeper 3.5.6

centos7

 
Reporter: Sheng Zhang


I run standalone cluster with 2 nodes hadoop101, hadoop102

jobmanager on hadoop101, taskmanager on hadoop101,hadoop102, each task has 4 
slots

when I submit job like this, task execute in one node,

./bin/flink run -d -p 2 ./examples/streaming/WordCount.jar

it does finish well.

but, when I submit job like this, task execute in different node,

./bin/flink run -d -p 6 ./examples/streaming/WordCount.jar

it does fail.

Here is the log:
org.apache.flink.runtime.JobException: Recovery is suppressed by 
NoRestartBackoffTimeStrategy
at 
org.apache.flink.runtime.executiongraph.failover.flip1.ExecutionFailureHandler.handleFailure(ExecutionFailureHandler.java:118)
at 
org.apache.flink.runtime.executiongraph.failover.flip1.ExecutionFailureHandler.getFailureHandlingResult(ExecutionFailureHandler.java:80)
at 
org.apache.flink.runtime.scheduler.DefaultScheduler.handleTaskFailure(DefaultScheduler.java:233)
at 
org.apache.flink.runtime.scheduler.DefaultScheduler.maybeHandleTaskFailure(DefaultScheduler.java:224)
at 
org.apache.flink.runtime.scheduler.DefaultScheduler.updateTaskExecutionStateInternal(DefaultScheduler.java:215)
at 
org.apache.flink.runtime.scheduler.SchedulerBase.updateTaskExecutionState(SchedulerBase.java:665)
at 
org.apache.flink.runtime.scheduler.SchedulerNG.updateTaskExecutionState(SchedulerNG.java:89)
at 
org.apache.flink.runtime.jobmaster.JobMaster.updateTaskExecutionState(JobMaster.java:447)
at jdk.internal.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.apache.flink.runtime.rpc.akka.AkkaRpcActor.handleRpcInvocation(AkkaRpcActor.java:306)
at 
org.apache.flink.runtime.rpc.akka.AkkaRpcActor.handleRpcMessage(AkkaRpcActor.java:213)
at 
org.apache.flink.runtime.rpc.akka.FencedAkkaRpcActor.handleRpcMessage(FencedAkkaRpcActor.java:77)
at 
org.apache.flink.runtime.rpc.akka.AkkaRpcActor.handleMessage(AkkaRpcActor.java:159)
at akka.japi.pf.UnitCaseStatement.apply(CaseStatements.scala:26)
at akka.japi.pf.UnitCaseStatement.apply(CaseStatements.scala:21)
at scala.PartialFunction.applyOrElse(PartialFunction.scala:123)
at scala.PartialFunction.applyOrElse$(PartialFunction.scala:122)
at akka.japi.pf.UnitCaseStatement.applyOrElse(CaseStatements.scala:21)
at scala.PartialFunction$OrElse.applyOrElse(PartialFunction.scala:171)
at scala.PartialFunction$OrElse.applyOrElse(PartialFunction.scala:172)
at scala.PartialFunction$OrElse.applyOrElse(PartialFunction.scala:172)
at akka.actor.Actor.aroundReceive(Actor.scala:517)
at akka.actor.Actor.aroundReceive$(Actor.scala:515)
at akka.actor.AbstractActor.aroundReceive(AbstractActor.scala:225)
at akka.actor.ActorCell.receiveMessage(ActorCell.scala:592)
at akka.actor.ActorCell.invoke(ActorCell.scala:561)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:258)
at akka.dispatch.Mailbox.run(Mailbox.scala:225)
at akka.dispatch.Mailbox.exec(Mailbox.scala:235)
at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
at 
akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
at 
akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
Caused by: 
org.apache.flink.runtime.io.network.partition.PartitionNotFoundException: 
Partition 27a57757dafad6d6d172b7fadf52597e#2@f8ca6485f4019d60a7700748e3f0c402 
not found.
at 
org.apache.flink.runtime.io.network.partition.consumer.RemoteInputChannel.failPartitionRequest(RemoteInputChannel.java:269)
at 
org.apache.flink.runtime.io.network.partition.consumer.RemoteInputChannel.retriggerSubpartitionRequest(RemoteInputChannel.java:187)
at 
org.apache.flink.runtime.io.network.partition.consumer.SingleInputGate.retriggerPartitionRequest(SingleInputGate.java:513)
at 
org.apache.flink.runtime.io.network.partition.consumer.SingleInputGate.lambda$triggerPartitionStateCheck$0(SingleInputGate.java:831)
at 
java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714)
at 
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at 

Re: [VOTE] Release 1.12.2, release candidate #1

[Xintong Song]

+1 (non-binding)

- verified checksums & signatures
- reviewed website PR
- build from source
- run example jobs
  - standalone session & yarn per-job
  - jobs work as expected
  - ui & logs look good

Thank you~

Xintong Song



On Fri, Feb 19, 2021 at 9:59 PM Piotr Nowojski  wrote:

> Hi,
>
> Thanks for preparing this release candidate.
>
> +1 from my side
>
> 1. I was monitoring recent builds for Unaligned Checkpoint issues and I can
> confirm that it seems we don't have any failures in the last couple of
> weeks.
> 2. There are no tickets with fix version set to 1.12.2. There are two
> blocker bugs for 1.12.3, but they are still quite far from being merged and
> they shouldn't block the 1.12.2 release, as they have been present in the
> past release already.
> 3. I double confirmed that there are no dependency changes between 1.12.1
> and 1.12.2-RC1, apart of the upgrade of `commons-beanutils` from 1.9.3 to
> 1.9.4, which had and maintained Apache 2.0 license.
>
> Piotrek
>
> pt., 19 lut 2021 o 10:24 Yuan Mei  napisał(a):
>
> > Hey Roman,
> >
> > Thanks for preparing RC1!
> >
> > +1 from my side.
> >
> > 1. Run-through UnalignedCheckpointITCase for 800+ rounds to make
> > sure UnalignedCheckpoint is stable
> > 2. Verified Checksums and GPG Signature
> > 3. Verified that the source archives do not contain any binaries
> > 4. Successfully Built the source with Maven, started a local Flink
> cluster,
> > and ran the streaming WordCount example with WebMonitor without
> suspicious
> > output
> > 5. Successfully ran the streaming WordCount example with the binary
> release
> > as well
> > 6. Checked for source and binary release to make sure both an Apache
> > License file and a NOTICE file are included
> > 7. Manually check all pom file changes since the last release (Flink
> > 1.12.1); no obvious license problem for me (Need someone to double
> confirm
> > this).
> >
> > Best
> > Yuan
> >
> > On Wed, Feb 17, 2021 at 3:25 AM Roman Khachatryan 
> > wrote:
> >
> > > Hi everyone,
> > > Please review and vote on the release candidate #1 for the version
> > 1.12.2,
> > > 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],
> > > * the official Apache source release and binary convenience releases to
> > be
> > > deployed to dist.apache.org [2], which are signed with the key with
> > > fingerprint 0D545F264D2DFDEBFD4E038F97B4625E2FCF517C [3],
> > > * all artifacts to be deployed to the Maven Central Repository [4],
> > > * source code tag "release-1.12.2-rc1" [5],
> > > * website pull request listing the new release and adding announcement
> > > blog post [6].
> > >
> > > The vote will be open for at least 72 hours. It is adopted by majority
> > > approval, with at least 3 PMC affirmative votes.
> > >
> > >
> > > Regards,
> > > Roman
> > >
> > > [1]
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12349502=12315522
> > > [2] https://dist.apache.org/repos/dist/dev/flink/flink-1.12.2-rc1/
> > > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> > > [4]
> > >
> https://repository.apache.org/content/repositories/orgapacheflink-1413/
> > > [5] https://github.com/apache/flink/releases/tag/release-1.12.2-rc1
> > > [6] https://github.com/apache/flink-web/pull/418
> > >
> >
>

Re: [ANNOUNCE] Welcome Roman Khachatryan a new Apache Flink Committer

[Zhu Zhu]

Congratulations Roman!

Thanks,
Zhu

Rui Li  于2021年2月20日周六 上午10:00写道：

> Congratulations Roman!
>
> On Thu, Feb 18, 2021 at 5:51 PM Congxian Qiu 
> wrote:
>
> > Congratulations, Roman
> > Best,
> > Congxian
> >
> >
> > Leonard Xu  于2021年2月18日周四 下午1:47写道：
> >
> > > Congrats Roman!
> > >
> > > Best,
> > > Leonard
> > >
> > > > 在 2021年2月18日，11:10，Yu Li  写道：
> > > >
> > > > Congratulations, Roman!
> > > >
> > > > Best Regards,
> > > > Yu
> > > >
> > > >
> > > > On Thu, 18 Feb 2021 at 11:05, Xingbo Huang 
> wrote:
> > > >
> > > >> Congratulations Roman!
> > > >>
> > > >> Best,
> > > >> Xingbo
> > > >>
> > > >> Yang Wang  于2021年2月18日周四 上午10:29写道：
> > > >>
> > > >>> Congrats Roman!
> > > >>>
> > > >>> Best,
> > > >>> Yang
> > > >>>
> > > >>> Xintong Song  于2021年2月18日周四 上午10:00写道：
> > > >>>
> > >  Congratulations, Roman~!
> > > 
> > >  Thank you~
> > > 
> > >  Xintong Song
> > > 
> > > 
> > > 
> > >  On Thu, Feb 18, 2021 at 9:42 AM Dian Fu 
> > > wrote:
> > > 
> > > > Congratulations, Roman!
> > > >
> > > > Regards,
> > > > Dian
> > > >
> > > >> 在 2021年2月16日，下午5:56，Yuan Mei  写道：
> > > >>
> > > >> Well deserved! Congrats Roman!
> > > >>
> > > >> Best,
> > > >> Yuan
> > > >>
> > > >> On Tue, Feb 16, 2021 at 5:10 PM Guowei Ma  >
> > >  wrote:
> > > >>
> > > >>> Congratulations Roman!
> > > >>> Best,
> > > >>> Guowei
> > > >>>
> > > >>>
> > > >>> On Thu, Feb 11, 2021 at 3:37 PM Yun Tang 
> > > >> wrote:
> > > >>>
> > >  Congratulations, Roman!
> > > 
> > >  Today is also the beginning of Chinese Spring Festival
> holiday,
> > > >> at
> > > > which
> > >  we Chinese celebrate across the world for the next lunar new
> > > >> year,
> > >  and
> > > >>> also
> > >  very happy to have you on board!
> > > 
> > >  Best
> > >  Yun Tang
> > >  
> > >  From: Roman Khachatryan 
> > >  Sent: Thursday, February 11, 2021 4:03
> > >  To: matth...@ververica.com 
> > >  Cc: dev 
> > >  Subject: Re: [ANNOUNCE] Welcome Roman Khachatryan a new Apache
> > > >>> Flink
> > >  Committer
> > > 
> > >  Many thanks to all of you!
> > > 
> > >  Regards,
> > >  Roman
> > > 
> > > 
> > >  On Wed, Feb 10, 2021 at 7:12 PM Matthias Pohl <
> > >  matth...@ververica.com>
> > >  wrote:
> > > 
> > > > Congratulations, Roman! :-)
> > > >
> > > > On Wed, Feb 10, 2021 at 3:23 PM Kezhu Wang  >
> > >  wrote:
> > > >
> > > >> Congratulations!
> > > >>
> > > >> Best,
> > > >> Kezhu Wang
> > > >>
> > > >>
> > > >> On February 10, 2021 at 21:53:52, Dawid Wysakowicz (
> > > >> dwysakow...@apache.org)
> > > >> wrote:
> > > >>
> > > >> Congratulations Roman! Glad to have you on board!
> > > >>
> > > >> Best,
> > > >>
> > > >> Dawid
> > > >>
> > > >> On 10/02/2021 14:44, Igal Shilman wrote:
> > > >>> Welcome Roman!
> > > >>> Top-notch stuff! :)
> > > >>>
> > > >>> All the best,
> > > >>> Igal.
> > > >>>
> > > >>> On Wed, Feb 10, 2021 at 2:15 PM Kostas Kloudas <
> > >  kklou...@gmail.com>
> > > >> wrote:
> > > >>>
> > >  Congrats Roman!
> > > 
> > >  Kostas
> > > 
> > >  On Wed, Feb 10, 2021 at 2:08 PM Arvid Heise <
> > > >> ar...@apache.org>
> > >  wrote:
> > > > 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
> > >  <
> > > >> ro...@apache.org>
> > > >> Subject:Re: [ANNOUNCE] Welcome Roman Khachatryan a new
> > > >> Apache
> > > >>> Flink
> > > >> Committer
> > > >> Congratulations Roman :-)
> > > >>
> > > >> Cheers,
> > > >> Till
> > > >>
> > > >> On Wed, Feb 10, 2021 at 1:01 PM Konstantin Knauf <
> > >  kna...@apache.org>
> > > >> wrote:
> > > >>
> > > >>> Congratulations Roman!
> > > >>>
> > > >>> On Wed, Feb 

Re: [DISCUSS]FLIP-163: SQL Client Improvements

[Shengkai Fang]

Hi everyone.

Sorry for the late response.

For `execution.runtime-mode`, I think it's much better than
`table.execution.mode`. Thanks for Timo's suggestions!

For `SHOW CREATE TABLE`, I'm +1 with Jark's comments. We should clarify the
usage of the SHOW CREATE TABLE statements. It should be allowed to specify
the table that is fully qualified and only works for the table that is
created by the sql statements.

I have updated the FLIP with suggestions. It seems we have reached a
consensus, I'd like to start a formal vote for the FLIP.

Please vote +1 to approve the FLIP, or -1 with a comment.

Best,
Shengkai

Jark Wu  于2021年2月15日周一 下午10:50写道：

> Hi Ingo,
>
> 1) I think you are right, the table path should be fully-qualified.
>
> 2) I think this is also a good point. The SHOW CREATE TABLE
> only aims to print DDL for the tables registered using SQL CREATE TABLE
> DDL.
> If a table is registered using Table API,  e.g.
> `StreamTableEnvironment#createTemporaryView(String, DataStream)`,
> currently it's not possible to print DDL for such tables.
> I think we should point it out in the FLIP.
>
> Best,
> Jark
>
>
>
> On Mon, 15 Feb 2021 at 21:33, Ingo Bürk  wrote:
>
> > Hi all,
> >
> > I have a couple questions about the SHOW CREATE TABLE statement.
> >
> > 1) Contrary to the example in the FLIP I think the returned DDL should
> > always have the table identifier fully-qualified. Otherwise the DDL
> depends
> > on the current context (catalog/database), which could be surprising,
> > especially since "the same" table can behave differently if created in
> > different catalogs.
> > 2) How should this handle tables which cannot be fully characterized by
> > properties only? I don't know if there's an example for this yet, but
> > hypothetically this is not currently a requirement, right? This isn't as
> > much of a problem if this syntax is SQL-client-specific, but if it's
> > general Flink SQL syntax we should consider this (one way or another).
> >
> >
> > Regards
> > Ingo
> >
> > On Fri, Feb 12, 2021 at 3:53 PM Timo Walther  wrote:
> >
> > > Hi Shengkai,
> > >
> > > thanks for updating the FLIP.
> > >
> > > I have one last comment for the option `table.execution.mode`. Should
> we
> > > already use the global Flink option `execution.runtime-mode` instead?
> > >
> > > We are using Flink's options where possible (e.g. `pipeline.name` and
> > > `parallism.default`) why not also for batch/streaming mode?
> > >
> > > The description of the option matches to the Blink planner behavior:
> > >
> > > ```
> > > Among other things, this controls task scheduling, network shuffle
> > > behavior, and time semantics.
> > > ```
> > >
> > > Regards,
> > > Timo
> > >
> > > On 10.02.21 06:30, Shengkai Fang wrote:
> > > > Hi, guys.
> > > >
> > > > I have updated the FLIP.  It seems we have reached agreement. Maybe
> we
> > > can
> > > > start the vote soon. If anyone has other questions, please leave your
> > > > comments.
> > > >
> > > > Best，
> > > > Shengkai
> > > >
> > > > Rui Li 于2021年2月9日 周二下午7:52写道：
> > > >
> > > >> Hi guys,
> > > >>
> > > >> The conclusion sounds good to me.
> > > >>
> > > >> On Tue, Feb 9, 2021 at 5:39 PM Shengkai Fang 
> > wrote:
> > > >>
> > > >>> Hi, Timo, Jark.
> > > >>>
> > > >>> I am fine with the new option name.
> > > >>>
> > > >>> Best,
> > > >>> Shengkai
> > > >>>
> > > >>> Timo Walther 于2021年2月9日 周二下午5:35写道：
> > > >>>
> > >  Yes, `TableEnvironment#executeMultiSql()` can be future work.
> > > 
> > >  @Rui, Shengkai: Are you also fine with this conclusion?
> > > 
> > >  Thanks,
> > >  Timo
> > > 
> > >  On 09.02.21 10:14, Jark Wu wrote:
> > > > I'm fine with `table.multi-dml-sync`.
> > > >
> > > > My previous concern about "multi" is that DML in CLI looks like
> > > >> single
> > > > statement.
> > > > But we can treat CLI as a multi-line accepting statements from
> > > >> opening
> > > >>> to
> > > > closing.
> > > > Thus, I'm fine with `table.multi-dml-sync`.
> > > >
> > > > So the conclusion is `table.multi-dml-sync` (false by default),
> and
> > > >> we
> > >  will
> > > > support this config
> > > > in SQL CLI first, will support it in
> > > >> TableEnvironment#executeMultiSql()
> > >  in
> > > > the future, right?
> > > >
> > > > Best,
> > > > Jark
> > > >
> > > > On Tue, 9 Feb 2021 at 16:37, Timo Walther 
> > > >> wrote:
> > > >
> > > >> Hi everyone,
> > > >>
> > > >> I understand Rui's concerns. `table.dml-sync` should not apply
> to
> > > >> regular `executeSql`. Actually, this option makes only sense
> when
> > > >> executing multi statements. Once we have a
> > > >> `TableEnvironment.executeMultiSql()` this config could be
> > > >> considered.
> > > >>
> > > >> Maybe we can find a better generic name? Other platforms will
> also
> > > >>> need
> > > >> to have this config option, which is why I would like to avoid a
> > SQL
> > > >> 

Re: [ANNOUNCE] Welcome Roman Khachatryan a new Apache Flink Committer

[Rui Li]

Congratulations Roman!

On Thu, Feb 18, 2021 at 5:51 PM Congxian Qiu  wrote:

> Congratulations, Roman
> Best,
> Congxian
>
>
> Leonard Xu  于2021年2月18日周四 下午1:47写道：
>
> > Congrats Roman!
> >
> > Best,
> > Leonard
> >
> > > 在 2021年2月18日，11:10，Yu Li  写道：
> > >
> > > Congratulations, Roman!
> > >
> > > Best Regards,
> > > Yu
> > >
> > >
> > > On Thu, 18 Feb 2021 at 11:05, Xingbo Huang  wrote:
> > >
> > >> Congratulations Roman!
> > >>
> > >> Best,
> > >> Xingbo
> > >>
> > >> Yang Wang  于2021年2月18日周四 上午10:29写道：
> > >>
> > >>> Congrats Roman!
> > >>>
> > >>> Best,
> > >>> Yang
> > >>>
> > >>> Xintong Song  于2021年2月18日周四 上午10:00写道：
> > >>>
> >  Congratulations, Roman~!
> > 
> >  Thank you~
> > 
> >  Xintong Song
> > 
> > 
> > 
> >  On Thu, Feb 18, 2021 at 9:42 AM Dian Fu 
> > wrote:
> > 
> > > Congratulations, Roman!
> > >
> > > Regards,
> > > Dian
> > >
> > >> 在 2021年2月16日，下午5:56，Yuan Mei  写道：
> > >>
> > >> Well deserved! Congrats Roman!
> > >>
> > >> Best,
> > >> Yuan
> > >>
> > >> On Tue, Feb 16, 2021 at 5:10 PM Guowei Ma 
> >  wrote:
> > >>
> > >>> Congratulations Roman!
> > >>> Best,
> > >>> Guowei
> > >>>
> > >>>
> > >>> On Thu, Feb 11, 2021 at 3:37 PM Yun Tang 
> > >> wrote:
> > >>>
> >  Congratulations, Roman!
> > 
> >  Today is also the beginning of Chinese Spring Festival holiday,
> > >> at
> > > which
> >  we Chinese celebrate across the world for the next lunar new
> > >> year,
> >  and
> > >>> also
> >  very happy to have you on board!
> > 
> >  Best
> >  Yun Tang
> >  
> >  From: Roman Khachatryan 
> >  Sent: Thursday, February 11, 2021 4:03
> >  To: matth...@ververica.com 
> >  Cc: dev 
> >  Subject: Re: [ANNOUNCE] Welcome Roman Khachatryan a new Apache
> > >>> Flink
> >  Committer
> > 
> >  Many thanks to all of you!
> > 
> >  Regards,
> >  Roman
> > 
> > 
> >  On Wed, Feb 10, 2021 at 7:12 PM Matthias Pohl <
> >  matth...@ververica.com>
> >  wrote:
> > 
> > > Congratulations, Roman! :-)
> > >
> > > On Wed, Feb 10, 2021 at 3:23 PM Kezhu Wang 
> >  wrote:
> > >
> > >> Congratulations!
> > >>
> > >> Best,
> > >> Kezhu Wang
> > >>
> > >>
> > >> On February 10, 2021 at 21:53:52, Dawid Wysakowicz (
> > >> dwysakow...@apache.org)
> > >> wrote:
> > >>
> > >> Congratulations Roman! Glad to have you on board!
> > >>
> > >> Best,
> > >>
> > >> Dawid
> > >>
> > >> On 10/02/2021 14:44, Igal Shilman wrote:
> > >>> Welcome Roman!
> > >>> Top-notch stuff! :)
> > >>>
> > >>> All the best,
> > >>> Igal.
> > >>>
> > >>> On Wed, Feb 10, 2021 at 2:15 PM Kostas Kloudas <
> >  kklou...@gmail.com>
> > >> wrote:
> > >>>
> >  Congrats Roman!
> > 
> >  Kostas
> > 
> >  On Wed, Feb 10, 2021 at 2:08 PM Arvid Heise <
> > >> ar...@apache.org>
> >  wrote:
> > > 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
> >  <
> > >> ro...@apache.org>
> > >> Subject:Re: [ANNOUNCE] Welcome Roman Khachatryan a new
> > >> Apache
> > >>> Flink
> > >> Committer
> > >> Congratulations Roman :-)
> > >>
> > >> Cheers,
> > >> Till
> > >>
> > >> On Wed, Feb 10, 2021 at 1:01 PM Konstantin Knauf <
> >  kna...@apache.org>
> > >> wrote:
> > >>
> > >>> Congratulations Roman!
> > >>>
> > >>> On Wed, Feb 10, 2021 at 11:29 AM Piotr Nowojski <
> >  pnowoj...@apache.org>
> > >>> wrote:
> > >>>
> >  Hi everyone,
> > 
> >  I'm very happy to announce that Roman Khachatryan has
> >  accepted
> >  the
> >  invitation to
> >  become a Flink committer.
> > 
> >  Roman has been recently active in 

[jira] [Created] (FLINK-21422) Migrate StateFun docs to hugo

[Seth Wiesman (Jira)]

Seth Wiesman created FLINK-21422:


 Summary: Migrate StateFun docs to hugo 
 Key: FLINK-21422
 URL: https://issues.apache.org/jira/browse/FLINK-21422
 Project: Flink
  Issue Type: Improvement
  Components: Documentation, Stateful Functions
Reporter: Seth Wiesman
Assignee: Seth Wiesman






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (FLINK-21421) Add coMapWithState to ConnnectedStreams

[Aris Koliopoulos (Jira)]

Aris Koliopoulos created FLINK-21421:


 Summary: Add coMapWithState to ConnnectedStreams
 Key: FLINK-21421
 URL: https://issues.apache.org/jira/browse/FLINK-21421
 Project: Flink
  Issue Type: New Feature
  Components: API / Scala
Reporter: Aris Koliopoulos


Currently there is no syntactic sugar for stateful functions in 
`ConnectedStreams` in Scala. 

This makes stateful joins (aka `connect`) more verbose and exposes users to 
Java interfaces (by requiring a `RichCoMapFunction` implementation to access 
state in `ConnectedStreams`).

Looking at DriveTribe's codebase, we have implemented ~80% of our 
ConnectedStreams operators using this `coMapWithState` implementation:

[https://github.com/ariskk/flink-stream-join/blob/main/src/main/scala/com/ariskk/streamjoin/ConnectedStreamsOps.scala#L15]

A `coFlatMapWithState` can be trivially implemented on top.

This has been in production for so long I forgot it was our code and not 
Flink's.

I can easily add it if this is of interest. No worries if not.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Release 1.12.2, release candidate #1

[Piotr Nowojski]

Hi,

Thanks for preparing this release candidate.

+1 from my side

1. I was monitoring recent builds for Unaligned Checkpoint issues and I can
confirm that it seems we don't have any failures in the last couple of
weeks.
2. There are no tickets with fix version set to 1.12.2. There are two
blocker bugs for 1.12.3, but they are still quite far from being merged and
they shouldn't block the 1.12.2 release, as they have been present in the
past release already.
3. I double confirmed that there are no dependency changes between 1.12.1
and 1.12.2-RC1, apart of the upgrade of `commons-beanutils` from 1.9.3 to
1.9.4, which had and maintained Apache 2.0 license.

Piotrek

pt., 19 lut 2021 o 10:24 Yuan Mei  napisał(a):

> Hey Roman,
>
> Thanks for preparing RC1!
>
> +1 from my side.
>
> 1. Run-through UnalignedCheckpointITCase for 800+ rounds to make
> sure UnalignedCheckpoint is stable
> 2. Verified Checksums and GPG Signature
> 3. Verified that the source archives do not contain any binaries
> 4. Successfully Built the source with Maven, started a local Flink cluster,
> and ran the streaming WordCount example with WebMonitor without suspicious
> output
> 5. Successfully ran the streaming WordCount example with the binary release
> as well
> 6. Checked for source and binary release to make sure both an Apache
> License file and a NOTICE file are included
> 7. Manually check all pom file changes since the last release (Flink
> 1.12.1); no obvious license problem for me (Need someone to double confirm
> this).
>
> Best
> Yuan
>
> On Wed, Feb 17, 2021 at 3:25 AM Roman Khachatryan 
> wrote:
>
> > Hi everyone,
> > Please review and vote on the release candidate #1 for the version
> 1.12.2,
> > 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],
> > * the official Apache source release and binary convenience releases to
> be
> > deployed to dist.apache.org [2], which are signed with the key with
> > fingerprint 0D545F264D2DFDEBFD4E038F97B4625E2FCF517C [3],
> > * all artifacts to be deployed to the Maven Central Repository [4],
> > * source code tag "release-1.12.2-rc1" [5],
> > * website pull request listing the new release and adding announcement
> > blog post [6].
> >
> > The vote will be open for at least 72 hours. It is adopted by majority
> > approval, with at least 3 PMC affirmative votes.
> >
> >
> > Regards,
> > Roman
> >
> > [1]
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12349502=12315522
> > [2] https://dist.apache.org/repos/dist/dev/flink/flink-1.12.2-rc1/
> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> > [4]
> > https://repository.apache.org/content/repositories/orgapacheflink-1413/
> > [5] https://github.com/apache/flink/releases/tag/release-1.12.2-rc1
> > [6] https://github.com/apache/flink-web/pull/418
> >
>

Re: [statefun] [Question] Path Templating in statefun-flink-datastream API

[Miguel Araújo]

Thanks, created FLINK-21420
.

Tzu-Li (Gordon) Tai  escreveu no dia sexta, 19/02/2021
à(s) 08:43:

> Hi Miguel,
>
> As Chesnay mentioned already, asking about the direction of some ongoing
> developed feature in the dev@ list is absolutely fine and correct.
> And it's indeed a good idea to open a JIRA ticket for this.
>
> As a quick pointer, I don't think there is any specific reason why path
> templating wasn't exposed in the DataStream API - this should be possible
> with some rework of the RequestReplyFunctionBuilder.
> I think it was initially left out as it's quite an isolated extended
> change to the core development of the path templating feature.
>
> If you'd like to open a JIRA on this, we'd be happy to move the discussion
> of adding feature to the ticket.
>
> Cheers,
> Joanne
>
> On Fri, Feb 19, 2021 at 3:30 AM Chesnay Schepler 
> wrote:
>
>> This is the right place to ask such questions; in fact I'd suggest to
>> just open a JIRA ticket.
>>
>> On 2/18/2021 2:50 PM, Miguel Araújo wrote:
>> > Apologies if this would be a better fit for the user mailing list, but I
>> > was unsure where to ask questions on (yet) unreleased functionality.
>> >
>> > I was really happy when I realized that FLINK-20334
>> >  was adding Path
>> > Templating, but it seems to me that the possibility was not added to the
>> > Data Stream API. I may be misunderstanding the codebase, but in
>> > SerializableHttpFunctionProvider#48 the HttpFunctionProvider is always
>> > instantiated with an empty map of perNamespaceEndpointSpecs, which
>> would be
>> > easy to change in the StatefulFunctionDataStreamBuilder.
>> >
>> > Is there a reason this wasn't considered? Is there anything tricky that
>> is
>> > blocking this addition, or maybe path templating is not relevant for the
>> > DataStream API and I'm not seeing the most appropriate way to achieve
>> the
>> > same goal?
>> >
>> > Thanks,
>> > Miguel
>> >
>>
>>

[jira] [Created] (FLINK-21420) Add path templating to DataStream API

[Miguel Araujo (Jira)]

Miguel Araujo created FLINK-21420:
-

 Summary: Add path templating to DataStream API
 Key: FLINK-21420
 URL: https://issues.apache.org/jira/browse/FLINK-21420
 Project: Flink
  Issue Type: Improvement
  Components: Stateful Functions
Reporter: Miguel Araujo


Path Template was introduced in FLINK-20264 with a new module YAML 
specification being added in FLINK-20334.

However, that possibility was not added to the DataStream API.

The main problem is that RequestReplyFunctionBuilder can only receive 
FunctionTypes which it then turns into FunctionTypeTarget's for the 
HttpFunctionEndpointSpec builder:
{code:java}
private RequestReplyFunctionBuilder(FunctionType functionType, URI endpoint) {
  this.builder =
  HttpFunctionEndpointSpec.builder(
  Target.functionType(functionType), new 
UrlPathTemplate(endpoint.toASCIIString()));
}
{code}
It should also be possible for the RequestReplyFunctionBuilder to receive a 
namespace instead of a function type and to use `Target.namespace(namespace)` 
to initialize the HttpFunctionEndpointSpec Builder instead.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

[Leonard Xu]

Hi, Joe

Thanks for volunteering to investigate the user data on this topic. Do you
have any progress here?

Thanks,
Leonard

On Thu, Feb 4, 2021 at 3:08 PM Johannes Moser  wrote:

> Hello,
>
> I will work with some users to get data on that.
>
> Thanks, Joe
>
> > On 03.02.2021, at 14:58, Stephan Ewen  wrote:
> >
> > Hi all!
> >
> > A quick thought on this thread: We see a typical stalemate here, as in so
> > many discussions recently.
> > One developer prefers it this way, another one another way. Both have
> > pro/con arguments, it takes a lot of time from everyone, still there is
> > little progress in the discussion.
> >
> > Ultimately, this can only be decided by talking to the users. And it
> > would also be the best way to ensure that what we build is the intuitive
> > and expected way for users.
> > The less the users are into the deep aspects of Flink SQL, the better
> they
> > can mirror what a common user would expect (a power user will anyways
> > figure it out).
> > Let's find a person to drive that, spell it out in the FLIP as "semantics
> > TBD", and focus on the implementation of the parts that are agreed upon.
> >
> > For interviewing the users, here are some ideas for questions to look at:
> >  - How do they view the trade-off between stable semantics vs.
> > out-of-the-box magic (faster getting started).
> >  - How comfortable are they realizing the different meaning of "now()" in
> > a streaming versus batch context.
> >  - What would be their expectation when moving a query with the time
> > functions ("now()") from an unbounded stream (Kafka source without end
> > offset) to a bounded stream (Kafka source with end offsets), which may
> > switch execution to batch.
> >
> > Best,
> > Stephan
> >
> >
> > On Tue, Feb 2, 2021 at 3:19 PM Jark Wu  wrote:
> >
> >> Hi Fabian,
> >>
> >> I think we have an agreement that the functions should be evaluated at
> >> query start in batch mode.
> >> Because all the other batch systems and traditional databases are this
> >> behavior, which is standard SQL compliant.
> >>
> >> *1. The different point of view is what's the behavior in streaming
> mode? *
> >>
> >> From my point of view, I don't see any potential meaning to evaluate at
> >> query-start for a 365-day long running streaming job.
> >> And from my observation, CURRENT_TIMESTAMP is heavily used by Flink
> >> streaming users and they expect the current behaviors.
> >> The SQL standard only provides a guideline for traditional batch
> systems,
> >> however Flink is a leading streaming processing system
> >> which is out of the scope of SQL standard, and Flink should define the
> >> streaming standard. I think a standard should follow users' intuition.
> >> Therefore, I think we don't need to be standard SQL compliant at this
> point
> >> because users don't expect it.
> >> Changing the behavior of the functions to evaluate at query start for
> >> streaming mode will hurt most of Flink SQL users and we have nothing to
> >> gain,
> >> we should avoid this.
> >>
> >> *2. Does it break the unified streaming-batch semantics? *
> >>
> >> I don't think so. First of all, what's the unified streaming-batch
> >> semantic?
> >> I think it means the* eventual result* instead of the *behavior*.
> >> It's hard to say we have provided unified behavior for streaming and
> batch
> >> jobs,
> >> because for example unbounded aggregate behaves very differently.
> >> In batch mode, it only evaluates once for the bounded data and emits the
> >> aggregate result once.
> >> But in streaming mode, it evaluates for each row and emits the updated
> >> result.
> >> What we have always emphasized "unified streaming-batch semantics" is
> [1]
> >>
> >>> a query produces exactly the same result regardless whether its input
> is
> >> static batch data or streaming data.
> >>
> >> From my understanding, the "semantic" means the "eventual result".
> >> And time functions are non-deterministic, so it's reasonable to get
> >> different results for batch and streaming mode.
> >> Therefore, I think it doesn't break the unified streaming-batch
> semantics
> >> to evaluate per-record for streaming and
> >> query-start for batch, as the semantic doesn't means behavior semantic.
> >>
> >> Best,
> >> Jark
> >>
> >> [1]: https://flink.apache.org/news/2017/04/04/dynamic-tables.html
> >>
> >> On Tue, 2 Feb 2021 at 18:34, Fabian Hueske  wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> Sorry for joining this discussion late.
> >>> Let me give some thought to two of the arguments raised in this thread.
> >>>
> >>> Time functions are inherently non-determintistic:
> >>> --
> >>> This is of course true, but IMO it doesn't mean that the semantics of
> >> time
> >>> functions do not matter.
> >>> It makes a difference whether a function is evaluated once and it's
> >> result
> >>> is reused or whether it is invoked for every record.
> >>> Would you use the same logic to justify different behavior of RAND() in
> >>> batch and streaming queries?
> >>>
> 

Re: [VOTE] Release 1.12.2, release candidate #1

[Yuan Mei]

Hey Roman,

Thanks for preparing RC1!

+1 from my side.

1. Run-through UnalignedCheckpointITCase for 800+ rounds to make
sure UnalignedCheckpoint is stable
2. Verified Checksums and GPG Signature
3. Verified that the source archives do not contain any binaries
4. Successfully Built the source with Maven, started a local Flink cluster,
and ran the streaming WordCount example with WebMonitor without suspicious
output
5. Successfully ran the streaming WordCount example with the binary release
as well
6. Checked for source and binary release to make sure both an Apache
License file and a NOTICE file are included
7. Manually check all pom file changes since the last release (Flink
1.12.1); no obvious license problem for me (Need someone to double confirm
this).

Best
Yuan

On Wed, Feb 17, 2021 at 3:25 AM Roman Khachatryan  wrote:

> Hi everyone,
> Please review and vote on the release candidate #1 for the version 1.12.2,
> 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],
> * the official Apache source release and binary convenience releases to be
> deployed to dist.apache.org [2], which are signed with the key with
> fingerprint 0D545F264D2DFDEBFD4E038F97B4625E2FCF517C [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag "release-1.12.2-rc1" [5],
> * website pull request listing the new release and adding announcement
> blog post [6].
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
>
> Regards,
> Roman
>
> [1]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12349502=12315522
> [2] https://dist.apache.org/repos/dist/dev/flink/flink-1.12.2-rc1/
> [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> [4]
> https://repository.apache.org/content/repositories/orgapacheflink-1413/
> [5] https://github.com/apache/flink/releases/tag/release-1.12.2-rc1
> [6] https://github.com/apache/flink-web/pull/418
>

[jira] [Created] (FLINK-21418) Replace MemorySegment.wrap() with processAsByteBuffer()

[Xintong Song (Jira)]

Xintong Song created FLINK-21418:


 Summary: Replace MemorySegment.wrap() with processAsByteBuffer()
 Key: FLINK-21418
 URL: https://issues.apache.org/jira/browse/FLINK-21418
 Project: Flink
  Issue Type: Sub-task
  Components: Runtime / Coordination
Reporter: Xintong Song






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (FLINK-21419) Remove GC cleaner mechanism for unsafe memory segments

[Xintong Song (Jira)]

Xintong Song created FLINK-21419:


 Summary: Remove GC cleaner mechanism for unsafe memory segments
 Key: FLINK-21419
 URL: https://issues.apache.org/jira/browse/FLINK-21419
 Project: Flink
  Issue Type: Sub-task
  Components: Runtime / Coordination
Reporter: Xintong Song






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (FLINK-21417) Separate type specific memory segments.

[Xintong Song (Jira)]

Xintong Song created FLINK-21417:


 Summary: Separate type specific memory segments.
 Key: FLINK-21417
 URL: https://issues.apache.org/jira/browse/FLINK-21417
 Project: Flink
  Issue Type: Sub-task
  Components: Runtime / Coordination
Reporter: Xintong Song
Assignee: Xintong Song






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [statefun] [Question] Path Templating in statefun-flink-datastream API

[Tzu-Li (Gordon) Tai]

Hi Miguel,

As Chesnay mentioned already, asking about the direction of some ongoing
developed feature in the dev@ list is absolutely fine and correct.
And it's indeed a good idea to open a JIRA ticket for this.

As a quick pointer, I don't think there is any specific reason why path
templating wasn't exposed in the DataStream API - this should be possible
with some rework of the RequestReplyFunctionBuilder.
I think it was initially left out as it's quite an isolated extended change
to the core development of the path templating feature.

If you'd like to open a JIRA on this, we'd be happy to move the discussion
of adding feature to the ticket.

Cheers,
Joanne

On Fri, Feb 19, 2021 at 3:30 AM Chesnay Schepler  wrote:

> This is the right place to ask such questions; in fact I'd suggest to
> just open a JIRA ticket.
>
> On 2/18/2021 2:50 PM, Miguel Araújo wrote:
> > Apologies if this would be a better fit for the user mailing list, but I
> > was unsure where to ask questions on (yet) unreleased functionality.
> >
> > I was really happy when I realized that FLINK-20334
> >  was adding Path
> > Templating, but it seems to me that the possibility was not added to the
> > Data Stream API. I may be misunderstanding the codebase, but in
> > SerializableHttpFunctionProvider#48 the HttpFunctionProvider is always
> > instantiated with an empty map of perNamespaceEndpointSpecs, which would
> be
> > easy to change in the StatefulFunctionDataStreamBuilder.
> >
> > Is there a reason this wasn't considered? Is there anything tricky that
> is
> > blocking this addition, or maybe path templating is not relevant for the
> > DataStream API and I'm not seeing the most appropriate way to achieve the
> > same goal?
> >
> > Thanks,
> > Miguel
> >
>
>

[jira] [Created] (FLINK-21416) FileBufferReaderITCase.testSequentialReading fails on azure

[Dawid Wysakowicz (Jira)]

Dawid Wysakowicz created FLINK-21416:


 Summary: FileBufferReaderITCase.testSequentialReading fails on 
azure
 Key: FLINK-21416
 URL: https://issues.apache.org/jira/browse/FLINK-21416
 Project: Flink
  Issue Type: Bug
  Components: Runtime / Network
Affects Versions: 1.13.0
Reporter: Dawid Wysakowicz


https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=13473=logs=59c257d0-c525-593b-261d-e96a86f1926b=b93980e3-753f-5433-6a19-13747adae66a

{code}
org.apache.flink.runtime.client.JobExecutionException: Job execution failed.
at 
org.apache.flink.runtime.jobmaster.JobResult.toJobExecutionResult(JobResult.java:144)
at 
org.apache.flink.runtime.minicluster.MiniCluster.executeJobBlocking(MiniCluster.java:811)
at 
org.apache.flink.runtime.io.network.partition.FileBufferReaderITCase.testSequentialReading(FileBufferReaderITCase.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.apache.flink.util.TestNameProvider$1.evaluate(TestNameProvider.java:45)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at 
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: org.apache.flink.runtime.JobException: Recovery is suppressed by 
NoRestartBackoffTimeStrategy
at 
org.apache.flink.runtime.executiongraph.failover.flip1.ExecutionFailureHandler.handleFailure(ExecutionFailureHandler.java:117)
at 
org.apache.flink.runtime.executiongraph.failover.flip1.ExecutionFailureHandler.getFailureHandlingResult(ExecutionFailureHandler.java:79)
at 
org.apache.flink.runtime.scheduler.DefaultScheduler.handleTaskFailure(DefaultScheduler.java:221)
at 
org.apache.flink.runtime.scheduler.DefaultScheduler.maybeHandleTaskFailure(DefaultScheduler.java:212)
at 
org.apache.flink.runtime.scheduler.DefaultScheduler.updateTaskExecutionStateInternal(DefaultScheduler.java:203)
at 
org.apache.flink.runtime.scheduler.SchedulerBase.updateTaskExecutionState(SchedulerBase.java:650)
at 

[jira] [Created] (FLINK-21415) JDBC does not query data, and the cache will store an ArrayList without data

[Shuai Xia (Jira)]

Shuai Xia created FLINK-21415:
-

 Summary: JDBC does not query data, and the cache will store an 
ArrayList without data
 Key: FLINK-21415
 URL: https://issues.apache.org/jira/browse/FLINK-21415
 Project: Flink
  Issue Type: Bug
  Components: Connectors / JDBC
Affects Versions: 1.12.1
Reporter: Shuai Xia


JDBC does not query data, and the cache will store an ArrayList without data.

We should add size judgment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)