[ANNOUNCE] Apache Flink Stateful Functions 2.2.1 released
The Apache Flink community released the first bugfix release of the Stateful Functions (StateFun) 2.2 series, version 2.2.1. This release fixes a critical bug that causes restoring a Stateful Functions cluster from snapshots (checkpoints or savepoints) to fail under certain conditions. *We strongly recommend all users to upgrade to this version.* *Please check out the release announcement for details on upgrading to 2.2.1:*https://flink.apache.org/news/2020/11/11/release-statefun-2.2.1.html The release is available for download at: https://flink.apache.org/downloads.html Maven artifacts for Stateful Functions can be found at: https://search.maven.org/search?q=g:org.apache.flink%20statefun Python SDK for Stateful Functions published to the PyPI index can be found at: https://pypi.org/project/apache-flink-statefun/ Official Dockerfiles for building Stateful Functions Docker images can be found at: https://github.com/apache/flink-statefun-docker Alternatively, Ververica has volunteered to make Stateful Function's images available for the community via their public Docker Hub registry: https://hub.docker.com/r/ververica/flink-statefun The full release notes are available in Jira: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12349291 We would like to thank all contributors of the Apache Flink community who made this release possible! Cheers, Gordon
[jira] [Created] (FLINK-20086) Add documentation for the open method in UserDefinedFunction
Dian Fu created FLINK-20086: --- Summary: Add documentation for the open method in UserDefinedFunction Key: FLINK-20086 URL: https://issues.apache.org/jira/browse/FLINK-20086 Project: Flink Issue Type: Improvement Components: API / Python, Documentation Reporter: Dian Fu Fix For: 1.12.0, 1.11.3 According to the questions asked by PyFlink users so far, many users are not aware that there is a open method in UserDefinedFunction where they could perform initialization work. This method is especially useful for ML users where they could do ML mode initialization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Releasing Apache Flink 1.11.3
Hi, I'd like FLINK-20079 [1] to be merged into 1.11 and included in 1.11.3. [1] https://issues.apache.org/jira/browse/FLINK-20079 Regards, Roman On Tue, Nov 10, 2020 at 8:21 AM Xintong Song wrote: > Thanks for the notice, Dian. > > Thank you~ > > Xintong Song > > > > On Tue, Nov 10, 2020 at 10:19 AM Dian Fu wrote: > > > Hi Xintong, > > > > I want to bring one more issue to your attention [1]. The test case > > UnalignedCheckpointCompatibilityITCase.test failed several times in the > > last nightly test of release-1.11. We need to figure out if it's just an > > instable test or caused by recent changes. > > > > [1] https://issues.apache.org/jira/browse/FLINK-20065 > > > > > 在 2020年11月10日，上午9:24，Xintong Song 写道： > > > > > > Thanks for the replies. > > > > > > Thank you~ > > > > > > Xintong Song > > > > > > > > > > > > On Tue, Nov 10, 2020 at 1:09 AM Becket Qin > wrote: > > > > > >> Hi Xintong, > > >> > > >> Thanks for driving the release. Just want to sync up on the FLIP-27 > > >> backporting. Stephan and I are still trying to backport a bunch of > > patches > > >> of Source to 1.11.3. Including: > > >> > > >> [FLINK-19698][connector/common] Add a close() method to the > SplitReader. > > >> [FLINK-19717] SourceReaderBase.pollNext may return END_OF_INPUT if > > >> SplitReader.fetch throws > > >> [FLINK-19535] [connector/common] Avoid failing a job multiple times in > > >> SourceCoordinator. > > >> [FLINK-19265] [FLINK-20049][core] Source API final adjustments. > > >> > > >> and a few more fixes. > > >> > > >> We are currently trying to fix them in 1.12 first so it might take a > > little > > >> longer to backport them to 1.11.3. I think it will probably take us a > > few > > >> more days to finish the backport. So that would roughly be the end of > > this > > >> week. > > >> > > >> Thanks, > > >> > > >> Jiangjie (Becket) Qin > > >> > > >> > > >> > > >> > > >> On Mon, Nov 9, 2020 at 9:57 PM Till Rohrmann > > wrote: > > >> > > >>> Yes, I've downgraded FLINK-19816 to critical. > > >>> > > >>> Cheers, > > >>> Till > > >>> > > >>> On Mon, Nov 9, 2020 at 10:19 AM Xintong Song > > >>> wrote: > > >>> > > Thanks for the notice, Till. > > > > I just checked and found FLINK-20033 is already fixed. Shall we also > > downgrade FLINK-19816 to `Critical`? > > > > Thank you~ > > > > Xintong Song > > > > > > > > On Mon, Nov 9, 2020 at 4:42 PM Till Rohrmann > > >>> wrote: > > > > > I would like to bring one more critical issue to your attention > which > > >>> is > > > FLINK-20033 [1]. I believe that this issue is actually causing what > > >> has > > > been reported in FLINK-19816 [2]. I hope to have it fixed by the > end > > >> of > > > today. Once FLINK-20033 is fixed, I think that we don't have to > block > > >>> the > > > release on FLINK-19816. > > > > > > [1] https://issues.apache.org/jira/browse/FLINK-20033 > > > [2] https://issues.apache.org/jira/browse/FLINK-19816 > > > > > > Cheers, > > > Till > > > > > > On Mon, Nov 9, 2020 at 4:05 AM Xintong Song > > > wrote: > > > > > >> Hi devs, > > >> > > >> I'd like to provide an update on the progress of preparing release > > > 1.11.3. > > >> > > >> *Blockers* > > >> We currently have 3 remaining blockers. (3 resolved and 1 emerged > > > compared > > >> to last week) > > >> > > >> - [FLINK-19698] Add close() method and onCheckpointComplete() to > > >> the > > >> Source. > > >> The issue has been fixed on the master branch. It's currently > > >> blocked > > on > > >> the FLIP-27 backportings to backport it to the 1.11 branch. > > >> > > >> - [FLINK-19717] SourceReaderBase.pollNext may return END_OF_INPUT > > >> if > > >> SplitReader.fetch throws > > >> A PR has been opened and reviewed. From the discussions on the PR, > > >> it > > > looks > > >> close to mergeable. > > >> > > >> - [FLINK-19816] Flink restored from a wrong checkpoint (a very old > > >>> one > > > and > > >> not the last completed one) > > >> This is a newly emerged blocker and Matthias is working on it. > > >> > > >> *Test Instabilities* > > >> We currently have 27 test instabilities[1]. > > >> AFAIK, none of them are as serious as to block the 1.11.3 release. > > >> > > >> *FLIP-27 Backprotings* > > >> > > >> I noticed that there's no jira issues opened on the FLIP-27 > > >>> backporting > > >> efforts, which is part of the major efforts planned for the 1.11.3 > > > release, > > >> making it hard to track the progress. > > >> > > >> > > >> @Stephan and @Becket, could you please share the updates on the > > > backporting > > >> efforts? How is the progress and when are the efforts expected to > > >> be > > >> finished? It would be appreciated and helpful if we can have a > jira > > > ticket > > >
Re: [VOTE] FLIP-145: Support SQL windowing table-valued function (2nd)
+1 (binding) Thanks, Timo On 11.11.20 07:14, Pengcheng Liu wrote: +1 (binding) Jark Wu 于2020年11月11日周三 上午10:13写道： +1 (binding) On Tue, 10 Nov 2020 at 14:59, Jark Wu wrote: Hi all, There is new feedback on the FLIP-145. So I would like to start a new vote for FLIP-145 [1], which has been discussed and reached consensus in the discussion thread [2]. The vote will be open until 15:00 (UTC+8) 13th Nov. (72h), unless there is an objection or not enough votes. Best, Jark [1]: https://cwiki.apache.org/confluence/display/FLINK/FLIP-145%3A+Support+SQL+windowing+table-valued+function [2]: http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-145-Support-SQL-windowing-table-valued-function-td45269.html
[jira] [Created] (FLINK-20087) CheckpointCoordinator waits until all tasks finish initialization of states to trigger checkpoint
Jiayi Liao created FLINK-20087:
--
Summary: CheckpointCoordinator waits until all tasks finish
initialization of states to trigger checkpoint
Key: FLINK-20087
URL: https://issues.apache.org/jira/browse/FLINK-20087
Project: Flink
Issue Type: Improvement
Components: Runtime / Checkpointing
Affects Versions: 1.9.0
Reporter: Jiayi Liao
{{CheckpointCoordinator}} will start triggering checkpoint after all tasks send
RUNNING status to JobMaster. However, the {{initializeState}} could be
time-expensive(a few minutes), for example the task needs to rescale with
multiple old tasks' rocksdb data. During this process, the triggering of
checkpoints are meaningless.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function (2nd)
+1 > -原始邮件- > 发件人: "Timo Walther" > 发送时间: 2020-11-11 18:55:06 (星期三) > 收件人: dev@flink.apache.org > 抄送: > 主题: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function (2nd) > > +1 (binding) > > Thanks, > Timo > > On 11.11.20 07:14, Pengcheng Liu wrote: > > +1 (binding) > > > > Jark Wu 于2020年11月11日周三 上午10:13写道： > > > >> +1 (binding) > >> > >> On Tue, 10 Nov 2020 at 14:59, Jark Wu wrote: > >> > >>> Hi all, > >>> > >>> There is new feedback on the FLIP-145. So I would like to start a new > >> vote > >>> for FLIP-145 [1], > >>> which has been discussed and reached consensus in the discussion thread > >>> [2]. > >>> > >>> The vote will be open until 15:00 (UTC+8) 13th Nov. (72h), unless there > >> is > >>> an objection or not enough votes. > >>> > >>> Best, > >>> Jark > >>> > >>> [1]: > >>> > >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-145%3A+Support+SQL+windowing+table-valued+function > >>> [2]: > >>> > >> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-145-Support-SQL-windowing-table-valued-function-td45269.html > >>> > >> > >
[jira] [Created] (FLINK-20088) [Kinesis][Polling] Issue using Polling consumer at timestamp with empty shard
Danny Cranmer created FLINK-20088:
-
Summary: [Kinesis][Polling] Issue using Polling consumer at
timestamp with empty shard
Key: FLINK-20088
URL: https://issues.apache.org/jira/browse/FLINK-20088
Project: Flink
Issue Type: Improvement
Components: Connectors / Kinesis
Reporter: Danny Cranmer
Fix For: 1.12.0
*Background*
The consumer fails when a Polling record publisher uses a timestamp sentinel
starting position and the first record batch is empty. This is because the
consumer tries to recalculate the start position from the timestamp sentinel,
this operation is not supported.
*Reproduction Steps*
Setup an application consuming from Kinesis with following properties and
consume from an empty shard:
{code:java}
String format = "-MM-dd'T'HH:mm:ss";
String date = new SimpleDateFormat(format).format(new Date());
consumerConfig.setProperty(ConsumerConfigConstants.STREAM_INITIAL_TIMESTAMP,
date);
consumerConfig.setProperty(ConsumerConfigConstants.STREAM_TIMESTAMP_DATE_FORMAT,
format);
consumerConfig.setProperty(ConsumerConfigConstants.STREAM_INITIAL_POSITION,
"AT_TIMESTAMP"); {code}
*Error*
{code:java}
Exception in thread "main"
org.apache.flink.runtime.client.JobExecutionException: Job execution
failed.Exception in thread "main"
org.apache.flink.runtime.client.JobExecutionException: Job execution failed. at
org.apache.flink.runtime.jobmaster.JobResult.toJobExecutionResult(JobResult.java:147)
at
org.apache.flink.runtime.minicluster.MiniClusterJobClient.lambda$getJobExecutionResult$2(MiniClusterJobClient.java:119)
at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:616)
at
java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:591)
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:488)
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1975)
at
org.apache.flink.runtime.rpc.akka.AkkaInvocationHandler.lambda$invokeRpc$0(AkkaInvocationHandler.java:229)
at
java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:774)
at
java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:750)
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:488)
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1975)
at
org.apache.flink.runtime.concurrent.FutureUtils$1.onComplete(FutureUtils.java:996)
at akka.dispatch.OnComplete.internal(Future.scala:264) at
akka.dispatch.OnComplete.internal(Future.scala:261) at
akka.dispatch.japi$CallbackBridge.apply(Future.scala:191) at
akka.dispatch.japi$CallbackBridge.apply(Future.scala:188) at
scala.concurrent.impl.CallbackRunnable.run$$$capture(Promise.scala:36) at
scala.concurrent.impl.CallbackRunnable.run(Promise.scala) at
org.apache.flink.runtime.concurrent.Executors$DirectExecutionContext.execute(Executors.java:74)
at scala.concurrent.impl.CallbackRunnable.executeWithValue(Promise.scala:44)
at scala.concurrent.impl.Promise$DefaultPromise.tryComplete(Promise.scala:252)
at akka.pattern.PromiseActorRef.$bang(AskSupport.scala:572) at
akka.pattern.PipeToSupport$PipeableFuture$$anonfun$pipeTo$1.applyOrElse(PipeToSupport.scala:22)
at
akka.pattern.PipeToSupport$PipeableFuture$$anonfun$pipeTo$1.applyOrElse(PipeToSupport.scala:21)
at scala.concurrent.Future$$anonfun$andThen$1.apply(Future.scala:436) at
scala.concurrent.Future$$anonfun$andThen$1.apply(Future.scala:435) at
scala.concurrent.impl.CallbackRunnable.run$$$capture(Promise.scala:36) at
scala.concurrent.impl.CallbackRunnable.run(Promise.scala) at
akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:55)
at
akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply$mcV$sp(BatchingExecutor.scala:91)
at
akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply(BatchingExecutor.scala:91)
at
akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply(BatchingExecutor.scala:91)
at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:72) at
akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:90) at
akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:40) at
akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:44)
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.JobException: Recovery is suppressed by
NoRestartBackoffTimeStrategy at
org.apache.flink.runtime.executiongraph.failover.flip1.ExecutionFailureHandler.handleFailure(Executio
[ANNOUNCE] Weekly Community Update 2020/44-45
Dear community, two weeks have passed again and I am happy two share another update with news on Flink 1.12, Flink 1.11.3 and the release of Stateful Functions 2.2.1. As everyone has been finishing the last bit and pieces of Flink 1.12, there are only a handful of new initiatives to cover this time including a so-called hybrid source and incremental checkpointing for the heap-based statebackends. Flink Development == * [releases] The feature freeze for Flink 1.12 happened on Monday and a first non-voting/testing release candidate has been published. [1] The community is collecting (manual) testing tasks in the wiki [2]. * [releases] There are still a few blockers to resolve before a first release candidate for Flink 1.11.3 is published. [3] * [releases] Stateful Functions 2.2.0 experiences a critical bug that causes restore from checkpoints or savepoints to fail in certain situations (FLINK-19692). The proper fix will be included in Flink 1.11.3. Since Flink 1.11.3 still takes a few days, Gordon proposed to release Stateful Functions 2.2.1 right away, that already fixes the issues when the framework version across snapshot creation and restore is the same. The release has already been approved and will be announced shortly. [4,5] * [sql] Jark has updated FLIP-145 after a round of offline discussions. The new windowing syntax will now also support session windows, propagate the window time as a time attribute and the FLIP proposes to deprecate the current GROUP BY window aggregation syntax. A new vote has been started based on the recent changes to the FLIP. [6,7] * [connectors] Nicholas Jiang has published a FLIP to support "Hybrid Sources". A Hybrid Source consists of multiple regular sources that are read from one after the other. Hybrid sources aim to make reprocessing/backfilling of data easier if the data is already distributed over multiple systems (e.g. last 14 days in Kafka, history in S3). [8] * [statebackends] Roman has published FLIP-151 to support incremental snapshotting for the heap-based state backend. Currently, incremental snapshotting is only supported by the RocksDBStatebackend. The HeapStatebackend is still preferable in a few situations and support for incremental checkpointing would overcome its largest limitation (besides limiting the state size to memory). [9] * [docker] In contrast to what I wrote would become the outcome of the discussion to make jemalloc the default memory allocator in the Apache Flink docker image, jemalloc will indeed become the default. [10] [1] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/ANNOUNCE-Feature-Freeze-of-Flink-1-12-tp46418.html [2] https://cwiki.apache.org/confluence/display/FLINK/1.12+Release+-+Community+Testing [3] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Releasing-Apache-Flink-1-11-3-tp45989.html [4] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Releasing-StateFun-hotfix-version-2-2-1-tp46239.html [5] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Apache-Flink-Stateful-Functions-2-2-1-release-candidate-1-tp46303.html [6] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-145-Support-SQL-windowing-table-valued-function-tp45269.html [7] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-FLIP-145-Support-SQL-windowing-table-valued-function-2nd-tp46452.html [8] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-151-Incremental-snapshots-for-heap-based-state-backend-tp46284.html [9] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Adopt-jemalloc-as-default-memory-allocator-in-docker-image-tp46382.html Notable Bugs == * [FLINK-19970][1.11.2] There might be a state leak in the CEP library that leads to an ever growing state size. I don't think this has been reproduced yet, but for anyone using the CEP library this is an interesting one to watch. [10] * [FLINK-20033] [1.11.2] [1.10.2] When a Job Master is stopped (which happens if the Dispatcher loses leadership) the current execution of its Job is failed, which can lead to data loss if the number of restarts are depleted. Fixed for 1.11.3 & 1.10.3. [11] [10] https://issues.apache.org/jira/browse/FLINK-19970 [11] https://issues.apache.org/jira/browse/FLINK-20033 Events, Blog Posts, Misc === * Congxian Qiu is now an Apache Flink Committer. Congratulations! [12] * Xianghu Wang has published a blog post outlining Apache Hudi's transition away from a Spark-only and towards a Flink-first architecture. [13] * Fred Teunissen & Erik de Nooij describe their solution to deal with event-time skew when ingesting data from heterogeneous Kafka partitions within one Flink Job on the Ververica Blog. [14] [12] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/ANNOUNCE-New-Apache-Flink-Committer-Congxian-Qiu-tp46123p46208.html [13] http://hudi.apache.org/blog/apache-hudi-meets-
[jira] [Created] (FLINK-20089) Avro format fails to serialize map value with null keys
hailong wang created FLINK-20089: Summary: Avro format fails to serialize map value with null keys Key: FLINK-20089 URL: https://issues.apache.org/jira/browse/FLINK-20089 Project: Flink Issue Type: Bug Components: Formats (JSON, Avro, Parquet, ORC, SequenceFile) Affects Versions: 1.12.0 Reporter: hailong wang When AvroRowDataSerializationSchema serializing map data with null keys, it will throw NPE. This is the same as [FLINK-19912|https://issues.apache.org/jira/projects/FLINK/issues/FLINK-19912] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-20090) Expose SlotId / SlotSharingGroup in Rest API
Maximilian Michels created FLINK-20090:
--
Summary: Expose SlotId / SlotSharingGroup in Rest API
Key: FLINK-20090
URL: https://issues.apache.org/jira/browse/FLINK-20090
Project: Flink
Issue Type: New Feature
Components: Runtime / REST
Reporter: Maximilian Michels
There is no information on slot sharing exposed via the Rest API which would be
useful to monitor how tasks are assigned to task slots.
We could include the SlotId in {{SubtaskExecutionAttemptDetailsInfo}} and
provide a list of slots in {{TaskManagersInfo}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-20091) Introduce avro.ignore-parse-errors for AvroRowDataDeserializationSchema
hailong wang created FLINK-20091: Summary: Introduce avro.ignore-parse-errors for AvroRowDataDeserializationSchema Key: FLINK-20091 URL: https://issues.apache.org/jira/browse/FLINK-20091 Project: Flink Issue Type: Improvement Components: Formats (JSON, Avro, Parquet, ORC, SequenceFile) Affects Versions: 1.12.0 Reporter: hailong wang Introduce avro.ignore-parse-errors to allow users to skip rows with parsing errors instead of failing when deserializing avro format data. This is useful when there are dirty data, for without this option, users can not skip the dirty row. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-20092) Multi-thread Flink compilation
Maciej Bryński created FLINK-20092:
--
Summary: Multi-thread Flink compilation
Key: FLINK-20092
URL: https://issues.apache.org/jira/browse/FLINK-20092
Project: Flink
Issue Type: Bug
Reporter: Maciej Bryński
I'd like to use maven -T option when compiling flink.
{code:java}
mvn -T 2C clean install -D"scala-2.12" -DskipTests{code}
Unfortunately my build is stuck on:
{code:java}
[INFO] --- maven-shade-plugin:3.2.1:shade (shade-flink) @
flink-fs-hadoop-shaded ---
[INFO] Including org.apache.hadoop:hadoop-common:jar:3.1.0 in the shaded jar.
[INFO] Including org.apache.hadoop:hadoop-annotations:jar:3.1.0 in the shaded
jar.
[INFO] Including com.google.guava:guava:jar:11.0.2 in the shaded jar.
[INFO] Including commons-io:commons-io:jar:2.7 in the shaded jar.
[INFO] Including commons-collections:commons-collections:jar:3.2.2 in the
shaded jar.
[INFO] Including commons-logging:commons-logging:jar:1.1.3 in the shaded jar.
[INFO] Including commons-lang:commons-lang:jar:2.6 in the shaded jar.
[INFO] Including commons-beanutils:commons-beanutils:jar:1.9.3 in the shaded
jar.
[INFO] Including org.apache.commons:commons-configuration2:jar:2.1.1 in the
shaded jar.
[INFO] Including org.apache.commons:commons-lang3:jar:3.3.2 in the shaded jar.
[INFO] Including com.google.re2j:re2j:jar:1.1 in the shaded jar.
[INFO] Including org.apache.hadoop:hadoop-auth:jar:3.1.0 in the shaded jar.
[INFO] Including org.apache.htrace:htrace-core4:jar:4.1.0-incubating in the
shaded jar.
[INFO] Including com.fasterxml.jackson.core:jackson-databind:jar:2.10.1 in the
shaded jar.
[INFO] Including com.fasterxml.jackson.core:jackson-annotations:jar:2.10.1 in
the shaded jar.
[INFO] Including com.fasterxml.jackson.core:jackson-core:jar:2.10.1 in the
shaded jar.
[INFO] Including org.codehaus.woodstox:stax2-api:jar:3.1.4 in the shaded jar.
[INFO] Including com.fasterxml.woodstox:woodstox-core:jar:5.0.3 in the shaded
jar.
[INFO] Including org.apache.flink:force-shading:jar:1.12-SNAPSHOT in the shaded
jar.
[INFO] No artifact matching filter io.netty:netty
[WARNING] Discovered module-info.class. Shading will break its strong
encapsulation.
[WARNING] Discovered module-info.class. Shading will break its strong
encapsulation.
[WARNING] Discovered module-info.class. Shading will break its strong
encapsulation.
[INFO] Replacing original artifact with shaded artifact.
[INFO] Replacing
/home/maverick/flink/flink-filesystems/flink-fs-hadoop-shaded/target/flink-fs-hadoop-shaded-1.12-SNAPSHOT.jar
with
/home/maverick/flink/flink-filesystems/flink-fs-hadoop-shaded/target/flink-fs-hadoop-shaded-1.12-SNAPSHOT-shaded.jar
[INFO] Dependency-reduced POM written at:
/home/maverick/flink/flink-filesystems/flink-fs-hadoop-shaded/target/dependency-reduced-pom.xml
{code}
Can we make flink compilation working with multiple maven threads ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Register processing time timers when Operator.close() is called
Hi! This is an interesting topic and we recently created a Jira issue about this: https://issues.apache.org/jira/browse/FLINK-18647. In Beam we even have a workaround for this: https://github.com/apache/beam/blob/0c01636fc8610414859d946cb93eabc904123fc8/runners/flink/src/main/java/org/apache/beam/runners/flink/translation/wrappers/streaming/DoFnOperator.java#L581 Maybe it's time to finally address this in Flink as well. Best, Aljoscha On 11.11.20 01:02, Boyuan Zhang wrote: Hi team, I'm writing my custom Operator as a high fan-out operation and I use processing time timers to defer processing some inputs When timers are firing, the operator will continue to process the deferred elements. One typical use case for my Operator is like: ImpulseOperator -> my Operator -> downstream where the watermark of ImpulseOperator advances to MAX_TIMESTAMP immediately. One problem I have is that after my operator.close() is called, it's still possible for me to set processing time timers and wait for these timers to be fired. But it seems like Flink pauses invoking processing timers once one operator.close() is called in the new version. I'm curious why Flink decides to do so and any workaround I can do for my operator? Thanks for your help!
[jira] [Created] (FLINK-20093) Create a download page for all optional sql client components
Dawid Wysakowicz created FLINK-20093: Summary: Create a download page for all optional sql client components Key: FLINK-20093 URL: https://issues.apache.org/jira/browse/FLINK-20093 Project: Flink Issue Type: Improvement Components: Documentation, Table SQL / Ecosystem Reporter: Dawid Wysakowicz Assignee: Dawid Wysakowicz Fix For: 1.12.0 It would be nice to have a single page that lists all optional binaries for sql client. We could link such a page from the "Optional components" section in the https://flink.apache.org/downloads.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-20094) Make JobMaster.jobStatusChanged directly called by JobManagerJobStatusListener
Till Rohrmann created FLINK-20094:
-
Summary: Make JobMaster.jobStatusChanged directly called by
JobManagerJobStatusListener
Key: FLINK-20094
URL: https://issues.apache.org/jira/browse/FLINK-20094
Project: Flink
Issue Type: Improvement
Components: Runtime / Coordination
Affects Versions: 1.12.0
Reporter: Till Rohrmann
Fix For: 1.13.0
Since the {{ExecutionGraph}} is only modified by the main thread, we no longer
need to splice the {{JobManagerJobStatusListener}} callbacks back into the
{{JobMaster's}} main thread using {{runAsync}}. Instead it should be possible
to directly call {{JobMaster.jobStatusChanged}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-20095) SchedulerBase.stopWithSavepoint schedules operation after ExecutionGraph terminates
Till Rohrmann created FLINK-20095:
-
Summary: SchedulerBase.stopWithSavepoint schedules operation after
ExecutionGraph terminates
Key: FLINK-20095
URL: https://issues.apache.org/jira/browse/FLINK-20095
Project: Flink
Issue Type: Improvement
Components: Runtime / Coordination
Affects Versions: 1.12.0
Reporter: Till Rohrmann
Fix For: 1.13.0
While looking into FLINK-20065, we realized that we cannot implement the change
described in FLINK-20094 because the {{SchedulerBase}} schedules an
asynchronous operation after the termination of the {{ExecutionGraph}}. This
asynchronous operation needs to complete before the savepoint path is returned.
In order to solve FLINK-20094, we either need to keep track of these operations
and suspend the {{SchedulerBase}} termination until all operations have
completed or we might be to return the savepoint path without depending it on
the completion of the {{handleAsync}} here:
https://github.com/apache/flink/blob/master/flink-runtime/src/main/java/org/apache/flink/runtime/scheduler/SchedulerBase.java#L921.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FLINK-20096) Clean up PyFlink documentation
Seth Wiesman created FLINK-20096: Summary: Clean up PyFlink documentation Key: FLINK-20096 URL: https://issues.apache.org/jira/browse/FLINK-20096 Project: Flink Issue Type: Bug Components: Documentation Reporter: Seth Wiesman Assignee: Seth Wiesman Fix For: 1.12.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-20097) Race conditions in InputChannel.ChannelStatePersister
Roman Khachatryan created FLINK-20097: - Summary: Race conditions in InputChannel.ChannelStatePersister Key: FLINK-20097 URL: https://issues.apache.org/jira/browse/FLINK-20097 Project: Flink Issue Type: Bug Components: Runtime / Checkpointing, Runtime / Network Affects Versions: 1.12.0 Reporter: Roman Khachatryan Assignee: Roman Khachatryan Fix For: 1.12.0 In InputChannel.ChannelStatePersister, stopPersisting() and checkForBarrier() always update pendingCheckpointBarrierId, potentially overwriting newer id (or BARRIER_RECEIVED value) with an old one. For stopPersisting(), consider a case: # Two consecutive UC barriers arrive at the same channel (1st being stale at some point) # In RemoteInputChannel.onBuffer, netty thread updates pendingCheckpointBarrierId to BARRIER_RECEIVED # Task thread processes the 1st barrier and triggers a checkpoint Task thread processes the 2nd barrier and aborts 1st checkpoint, calling stopPersisting() from UC controller and setting pendingCheckpointBarrierId to CHECKPOINT_COMPLETED # Task thread starts 2nd checkpoint and calls startPersisting() setting pendingCheckpointBarrierId to 2 # now new buffers have a chance to be included in the 2nd checkpoint (though they belong to the next one) For pendingCheckpointBarrierId(), consider an input gate with two channels A and B and two barriers 1 and 2: # Channel A receives both barriers, channel B receives nothing yet # Task thread processes both barriers on A, eventually triggering 2nd checkpoint # Channel A state is now BARRIER_RECEIVED, channel B - pending (with id=2) # Channel B receives the 1st barrier and becomes BARRIER_RECEIVED # No buffers in B between barriers 1 and 2 will be included in the checkpoint # Channel B receives the 2nd barrier which will eventually conclude the checkpoint I see a solution in doing an action only if passed checkpointId >= pendingCheckpointId. For that, a separate field will be needed to hold the status (RECEIVED/COMPLETED/PENDING). The class isn't thread-safe so it shouldn't be a problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FLINK-20098) Don't add flink-connector-files to flink-dist
Aljoscha Krettek created FLINK-20098:
Summary: Don't add flink-connector-files to flink-dist
Key: FLINK-20098
URL: https://issues.apache.org/jira/browse/FLINK-20098
Project: Flink
Issue Type: Bug
Components: API / DataStream
Reporter: Aljoscha Krettek
Assignee: Aljoscha Krettek
Fix For: 1.12.0
We currently add both {{flink-connector-files}} and {{flink-connector-base}} to
{{flink-dist}}.
This implies, that users should use the dependency like this:
{code}
org.apache.flink
flink-connector-files
${project.version}
provided
{code}
which differs from other connectors where users don't need to specify
{{provided}}.
Also, {{flink-connector-files}} has {{flink-connector-base}} as a provided
dependency, which means that examples that use this dependency will not run
out-of-box in IntelliJ because transitive provided dependencies will not be
considered.
I propose to just remove the dependencies from {{flink-dist}} and let users use
the File Connector like any other connector.
I believe the initial motivation for "providing" the File Connector in
{{flink-dist}} was to allow us to use the File Connector under the hood in
methods such as {{StreamExecutionEnvironment.readFile(...)}}. We could decide
to deprecate and remove those methods or re-add the File Connector as an
explicit (non-provided) dependency again in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Register processing time timers when Operator.close() is called
Thanks, Aljoscha! Manually draining processing time timers during operator.close() is my current workaround as well. It's just not efficient for me since I may set the processing time timer for the callback after 5 mins but now I need to fire them immediately. https://issues.apache.org/jira/browse/FLINK-18647 is really helpful and looking forward to the solution. Thanks for your help! On Wed, Nov 11, 2020 at 8:13 AM Aljoscha Krettek wrote: > Hi! > > This is an interesting topic and we recently created a Jira issue about > this: https://issues.apache.org/jira/browse/FLINK-18647. > > In Beam we even have a workaround for this: > > https://github.com/apache/beam/blob/0c01636fc8610414859d946cb93eabc904123fc8/runners/flink/src/main/java/org/apache/beam/runners/flink/translation/wrappers/streaming/DoFnOperator.java#L581 > > Maybe it's time to finally address this in Flink as well. > > Best, > Aljoscha > > > On 11.11.20 01:02, Boyuan Zhang wrote: > > Hi team, > > > > I'm writing my custom Operator as a high fan-out operation and I use > > processing time timers to defer processing some inputs When timers are > > firing, the operator will continue to process the deferred elements. One > > typical use case for my Operator is like: > > ImpulseOperator -> my Operator -> downstream where the watermark of > > ImpulseOperator advances to MAX_TIMESTAMP immediately. > > > > One problem I have is that after my operator.close() is called, it's > still > > possible for me to set processing time timers and wait for these timers > to > > be fired. But it seems like Flink pauses invoking processing timers once > > one operator.close() is called in the new version. I'm curious why Flink > > decides to do so and any workaround I can do for my operator? > > > > Thanks for your help! > > > >
[jira] [Created] (FLINK-20099) HeapStateBackend checkpoint error hidden under cryptic message
Nico Kruber created FLINK-20099:
---
Summary: HeapStateBackend checkpoint error hidden under cryptic
message
Key: FLINK-20099
URL: https://issues.apache.org/jira/browse/FLINK-20099
Project: Flink
Issue Type: Bug
Components: Runtime / Checkpointing, Runtime / State Backends
Affects Versions: 1.11.2
Reporter: Nico Kruber
Attachments: Screenshot_20201112_001331.png
When the memory state back-end hits a certain size, it fails to permit
checkpoints. Even though a very detailed exception is thrown at its source,
this is neither logged nor shown in the UI:
* Logs just contain:
{code:java}
00:06:41.462 [jobmanager-future-thread-14] INFO
org.apache.flink.runtime.checkpoint.CheckpointCoordinator - Decline checkpoint
2 by task 8eb303cd3196310cb2671212f4ed013c of job
c9b7a410bd3143864ca23ba89595d878 at 6a73bcf2-46b6-4735-a616-fdf09ff1471c @
localhost (dataPort=-1).
{code}
* UI: (also see the attached Screenshot_20201112_001331.png)
{code:java}
Failure Message: The job has failed.
{code}
-> this isn't even true: the job is still running fine!
Debugging into {{PendingCheckpoint#abort()}} reveals that the causing exception
is actually still in there but the detailed information from it is just never
used.
For reference, this is what is available there and should be logged or shown:
{code:java}
java.lang.Exception: Could not materialize checkpoint 2 for operator aggregates
-> (Sink: sink-agg-365, Sink: sink-agg-180, Sink: sink-agg-45, Sink:
sink-agg-30) (4/4).
at
org.apache.flink.streaming.runtime.tasks.AsyncCheckpointRunnable.handleExecutionException(AsyncCheckpointRunnable.java:191)
at
org.apache.flink.streaming.runtime.tasks.AsyncCheckpointRunnable.run(AsyncCheckpointRunnable.java:138)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Size
of the state is larger than the maximum permitted memory-backed state.
Size=6122737 , maxSize=5242880 . Consider using a different state backend, like
the File System State backend.
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at
org.apache.flink.runtime.concurrent.FutureUtils.runIfNotDoneAndGet(FutureUtils.java:479)
at
org.apache.flink.streaming.api.operators.OperatorSnapshotFinalizer.(OperatorSnapshotFinalizer.java:50)
at
org.apache.flink.streaming.runtime.tasks.AsyncCheckpointRunnable.run(AsyncCheckpointRunnable.java:102)
... 3 more
Caused by: java.io.IOException: Size of the state is larger than the maximum
permitted memory-backed state. Size=6122737 , maxSize=5242880 . Consider using
a different state backend, like the File System State backend.
at
org.apache.flink.runtime.state.memory.MemCheckpointStreamFactory.checkSize(MemCheckpointStreamFactory.java:64)
at
org.apache.flink.runtime.state.memory.MemCheckpointStreamFactory$MemoryCheckpointOutputStream.closeAndGetBytes(MemCheckpointStreamFactory.java:145)
at
org.apache.flink.runtime.state.memory.MemCheckpointStreamFactory$MemoryCheckpointOutputStream.closeAndGetHandle(MemCheckpointStreamFactory.java:126)
at
org.apache.flink.runtime.state.CheckpointStreamWithResultProvider$PrimaryStreamOnly.closeAndFinalizeCheckpointStreamResult(CheckpointStreamWithResultProvider.java:77)
at
org.apache.flink.runtime.state.heap.HeapSnapshotStrategy$1.callInternal(HeapSnapshotStrategy.java:199)
at
org.apache.flink.runtime.state.heap.HeapSnapshotStrategy$1.callInternal(HeapSnapshotStrategy.java:158)
at
org.apache.flink.runtime.state.AsyncSnapshotCallable.call(AsyncSnapshotCallable.java:75)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.flink.runtime.concurrent.FutureUtils.runIfNotDoneAndGet(FutureUtils.java:476)
... 5 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Releasing Apache Flink 1.11.3
Thanks for the notice and fix, Roman. Thank you~ Xintong Song On Wed, Nov 11, 2020 at 5:53 PM Khachatryan Roman < khachatryan.ro...@gmail.com> wrote: > Hi, > > I'd like FLINK-20079 [1] to be merged into 1.11 and included in 1.11.3. > > [1] https://issues.apache.org/jira/browse/FLINK-20079 > > Regards, > Roman > > > On Tue, Nov 10, 2020 at 8:21 AM Xintong Song > wrote: > > > Thanks for the notice, Dian. > > > > Thank you~ > > > > Xintong Song > > > > > > > > On Tue, Nov 10, 2020 at 10:19 AM Dian Fu wrote: > > > > > Hi Xintong, > > > > > > I want to bring one more issue to your attention [1]. The test case > > > UnalignedCheckpointCompatibilityITCase.test failed several times in the > > > last nightly test of release-1.11. We need to figure out if it's just > an > > > instable test or caused by recent changes. > > > > > > [1] https://issues.apache.org/jira/browse/FLINK-20065 > > > > > > > 在 2020年11月10日，上午9:24，Xintong Song 写道： > > > > > > > > Thanks for the replies. > > > > > > > > Thank you~ > > > > > > > > Xintong Song > > > > > > > > > > > > > > > > On Tue, Nov 10, 2020 at 1:09 AM Becket Qin > > wrote: > > > > > > > >> Hi Xintong, > > > >> > > > >> Thanks for driving the release. Just want to sync up on the FLIP-27 > > > >> backporting. Stephan and I are still trying to backport a bunch of > > > patches > > > >> of Source to 1.11.3. Including: > > > >> > > > >> [FLINK-19698][connector/common] Add a close() method to the > > SplitReader. > > > >> [FLINK-19717] SourceReaderBase.pollNext may return END_OF_INPUT if > > > >> SplitReader.fetch throws > > > >> [FLINK-19535] [connector/common] Avoid failing a job multiple times > in > > > >> SourceCoordinator. > > > >> [FLINK-19265] [FLINK-20049][core] Source API final adjustments. > > > >> > > > >> and a few more fixes. > > > >> > > > >> We are currently trying to fix them in 1.12 first so it might take a > > > little > > > >> longer to backport them to 1.11.3. I think it will probably take us > a > > > few > > > >> more days to finish the backport. So that would roughly be the end > of > > > this > > > >> week. > > > >> > > > >> Thanks, > > > >> > > > >> Jiangjie (Becket) Qin > > > >> > > > >> > > > >> > > > >> > > > >> On Mon, Nov 9, 2020 at 9:57 PM Till Rohrmann > > > wrote: > > > >> > > > >>> Yes, I've downgraded FLINK-19816 to critical. > > > >>> > > > >>> Cheers, > > > >>> Till > > > >>> > > > >>> On Mon, Nov 9, 2020 at 10:19 AM Xintong Song < > tonysong...@gmail.com> > > > >>> wrote: > > > >>> > > > Thanks for the notice, Till. > > > > > > I just checked and found FLINK-20033 is already fixed. Shall we > also > > > downgrade FLINK-19816 to `Critical`? > > > > > > Thank you~ > > > > > > Xintong Song > > > > > > > > > > > > On Mon, Nov 9, 2020 at 4:42 PM Till Rohrmann < > trohrm...@apache.org> > > > >>> wrote: > > > > > > > I would like to bring one more critical issue to your attention > > which > > > >>> is > > > > FLINK-20033 [1]. I believe that this issue is actually causing > what > > > >> has > > > > been reported in FLINK-19816 [2]. I hope to have it fixed by the > > end > > > >> of > > > > today. Once FLINK-20033 is fixed, I think that we don't have to > > block > > > >>> the > > > > release on FLINK-19816. > > > > > > > > [1] https://issues.apache.org/jira/browse/FLINK-20033 > > > > [2] https://issues.apache.org/jira/browse/FLINK-19816 > > > > > > > > Cheers, > > > > Till > > > > > > > > On Mon, Nov 9, 2020 at 4:05 AM Xintong Song < > tonysong...@gmail.com > > > > > > wrote: > > > > > > > >> Hi devs, > > > >> > > > >> I'd like to provide an update on the progress of preparing > release > > > > 1.11.3. > > > >> > > > >> *Blockers* > > > >> We currently have 3 remaining blockers. (3 resolved and 1 > emerged > > > > compared > > > >> to last week) > > > >> > > > >> - [FLINK-19698] Add close() method and onCheckpointComplete() to > > > >> the > > > >> Source. > > > >> The issue has been fixed on the master branch. It's currently > > > >> blocked > > > on > > > >> the FLIP-27 backportings to backport it to the 1.11 branch. > > > >> > > > >> - [FLINK-19717] SourceReaderBase.pollNext may return > END_OF_INPUT > > > >> if > > > >> SplitReader.fetch throws > > > >> A PR has been opened and reviewed. From the discussions on the > PR, > > > >> it > > > > looks > > > >> close to mergeable. > > > >> > > > >> - [FLINK-19816] Flink restored from a wrong checkpoint (a very > old > > > >>> one > > > > and > > > >> not the last completed one) > > > >> This is a newly emerged blocker and Matthias is working on it. > > > >> > > > >> *Test Instabilities* > > > >> We currently have 27 test instabilities[1]. > > > >> AFAIK, none of them are as serious as to block the 1.11.3 > release. > > > >> > > > >> *FLIP-27
[jira] [Created] (FLINK-20100) Lag aggregate function does not return lag, but current row
Thilo Schneider created FLINK-20100:
---
Summary: Lag aggregate function does not return lag, but current
row
Key: FLINK-20100
URL: https://issues.apache.org/jira/browse/FLINK-20100
Project: Flink
Issue Type: Bug
Components: API / Python
Affects Versions: 1.11.2
Reporter: Thilo Schneider
The lag aggregate function seems to always return the current row and not the
row one lagged behind:
{code:java}
from pyflink.table import EnvironmentSettings, StreamTableEnvironment
env_settings =
EnvironmentSettings.new_instance().in_streaming_mode().use_blink_planner().build()
t_env = StreamTableEnvironment.create( environment_settings=env_settings)
t_env.execute_sql("""
CREATE TABLE datagen (
foo INT,
message_time AS to_timestamp(from_unixtime(foo)),
WATERMARK FOR message_time AS message_time
) WITH (
'connector' = 'datagen',
'rows-per-second'='3',
'fields.foo.kind'='sequence',
'fields.foo.start'='1',
'fields.foo.end'='10'
)""")
t = t_env.sql_query("SELECT foo, lag(foo) OVER w AS lagfoo FROM datagen WINDOW
w AS (ORDER BY message_time)")
t_env.execute_sql("CREATE TABLE output (foo INT, lagfoo INT) WITH ('connector'
= 'print')")
t.execute_insert("output")
{code}
This results in
{code:java}
+I(1,1) // Expected (1, null)
+I(2,2) // Expected (2, 1)
+I(3,3) // Expected (3, 2)
+I(4,4) // and so on
+I(5,5)
+I(6,6)
+I(7,7)
+I(8,8)
+I(9,9)
+I(10,10)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re:Re: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function (2nd)
+1（no-binding） 在 2020-11-11 19:44:40，"刘大龙" 写道： > >+1 > >> -原始邮件- >> 发件人: "Timo Walther" >> 发送时间: 2020-11-11 18:55:06 (星期三) >> 收件人: dev@flink.apache.org >> 抄送: >> 主题: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function (2nd) >> >> +1 (binding) >> >> Thanks, >> Timo >> >> On 11.11.20 07:14, Pengcheng Liu wrote: >> > +1 (binding) >> > >> > Jark Wu 于2020年11月11日周三 上午10:13写道： >> > >> >> +1 (binding) >> >> >> >> On Tue, 10 Nov 2020 at 14:59, Jark Wu wrote: >> >> >> >>> Hi all, >> >>> >> >>> There is new feedback on the FLIP-145. So I would like to start a new >> >> vote >> >>> for FLIP-145 [1], >> >>> which has been discussed and reached consensus in the discussion thread >> >>> [2]. >> >>> >> >>> The vote will be open until 15:00 (UTC+8) 13th Nov. (72h), unless there >> >> is >> >>> an objection or not enough votes. >> >>> >> >>> Best, >> >>> Jark >> >>> >> >>> [1]: >> >>> >> >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-145%3A+Support+SQL+windowing+table-valued+function >> >>> [2]: >> >>> >> >> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-145-Support-SQL-windowing-table-valued-function-td45269.html >> >>> >> >> >> >
Re: Re: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function (2nd)
+1 On Thu, Nov 12, 2020 at 2:07 PM hailongwang <18868816...@163.com> wrote: > > > +1（no-binding） > > > > > 在 2020-11-11 19:44:40，"刘大龙" 写道： > > > >+1 > > > >> -原始邮件- > >> 发件人: "Timo Walther" > >> 发送时间: 2020-11-11 18:55:06 (星期三) > >> 收件人: dev@flink.apache.org > >> 抄送: > >> 主题: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function > (2nd) > >> > >> +1 (binding) > >> > >> Thanks, > >> Timo > >> > >> On 11.11.20 07:14, Pengcheng Liu wrote: > >> > +1 (binding) > >> > > >> > Jark Wu 于2020年11月11日周三 上午10:13写道： > >> > > >> >> +1 (binding) > >> >> > >> >> On Tue, 10 Nov 2020 at 14:59, Jark Wu wrote: > >> >> > >> >>> Hi all, > >> >>> > >> >>> There is new feedback on the FLIP-145. So I would like to start a > new > >> >> vote > >> >>> for FLIP-145 [1], > >> >>> which has been discussed and reached consensus in the discussion > thread > >> >>> [2]. > >> >>> > >> >>> The vote will be open until 15:00 (UTC+8) 13th Nov. (72h), unless > there > >> >> is > >> >>> an objection or not enough votes. > >> >>> > >> >>> Best, > >> >>> Jark > >> >>> > >> >>> [1]: > >> >>> > >> >> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-145%3A+Support+SQL+windowing+table-valued+function > >> >>> [2]: > >> >>> > >> >> > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-145-Support-SQL-windowing-table-valued-function-td45269.html > >> >>> > >> >> > >> > > -- Best, Jingsong Lee
Re: Re: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function (2nd)
+1 Jingsong Li 于2020年11月12日周四 下午2:18写道： > +1 > > On Thu, Nov 12, 2020 at 2:07 PM hailongwang <18868816...@163.com> wrote: > > > > > > > +1（no-binding） > > > > > > > > > > 在 2020-11-11 19:44:40，"刘大龙" 写道： > > > > > >+1 > > > > > >> -原始邮件- > > >> 发件人: "Timo Walther" > > >> 发送时间: 2020-11-11 18:55:06 (星期三) > > >> 收件人: dev@flink.apache.org > > >> 抄送: > > >> 主题: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function > > (2nd) > > >> > > >> +1 (binding) > > >> > > >> Thanks, > > >> Timo > > >> > > >> On 11.11.20 07:14, Pengcheng Liu wrote: > > >> > +1 (binding) > > >> > > > >> > Jark Wu 于2020年11月11日周三 上午10:13写道： > > >> > > > >> >> +1 (binding) > > >> >> > > >> >> On Tue, 10 Nov 2020 at 14:59, Jark Wu wrote: > > >> >> > > >> >>> Hi all, > > >> >>> > > >> >>> There is new feedback on the FLIP-145. So I would like to start a > > new > > >> >> vote > > >> >>> for FLIP-145 [1], > > >> >>> which has been discussed and reached consensus in the discussion > > thread > > >> >>> [2]. > > >> >>> > > >> >>> The vote will be open until 15:00 (UTC+8) 13th Nov. (72h), unless > > there > > >> >> is > > >> >>> an objection or not enough votes. > > >> >>> > > >> >>> Best, > > >> >>> Jark > > >> >>> > > >> >>> [1]: > > >> >>> > > >> >> > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-145%3A+Support+SQL+windowing+table-valued+function > > >> >>> [2]: > > >> >>> > > >> >> > > > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-145-Support-SQL-windowing-table-valued-function-td45269.html > > >> >>> > > >> >> > > >> > > > > > > -- > Best, Jingsong Lee >
Re: Re: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function (2nd)
+1 Danny Chan 于2020年11月12日周四 下午2:19写道： > +1 > > Jingsong Li 于2020年11月12日周四 下午2:18写道： > > > +1 > > > > On Thu, Nov 12, 2020 at 2:07 PM hailongwang <18868816...@163.com> wrote: > > > > > > > > > > > +1（no-binding） > > > > > > > > > > > > > > > 在 2020-11-11 19:44:40，"刘大龙" 写道： > > > > > > > >+1 > > > > > > > >> -原始邮件- > > > >> 发件人: "Timo Walther" > > > >> 发送时间: 2020-11-11 18:55:06 (星期三) > > > >> 收件人: dev@flink.apache.org > > > >> 抄送: > > > >> 主题: Re: [VOTE] FLIP-145: Support SQL windowing table-valued function > > > (2nd) > > > >> > > > >> +1 (binding) > > > >> > > > >> Thanks, > > > >> Timo > > > >> > > > >> On 11.11.20 07:14, Pengcheng Liu wrote: > > > >> > +1 (binding) > > > >> > > > > >> > Jark Wu 于2020年11月11日周三 上午10:13写道： > > > >> > > > > >> >> +1 (binding) > > > >> >> > > > >> >> On Tue, 10 Nov 2020 at 14:59, Jark Wu wrote: > > > >> >> > > > >> >>> Hi all, > > > >> >>> > > > >> >>> There is new feedback on the FLIP-145. So I would like to start > a > > > new > > > >> >> vote > > > >> >>> for FLIP-145 [1], > > > >> >>> which has been discussed and reached consensus in the discussion > > > thread > > > >> >>> [2]. > > > >> >>> > > > >> >>> The vote will be open until 15:00 (UTC+8) 13th Nov. (72h), > unless > > > there > > > >> >> is > > > >> >>> an objection or not enough votes. > > > >> >>> > > > >> >>> Best, > > > >> >>> Jark > > > >> >>> > > > >> >>> [1]: > > > >> >>> > > > >> >> > > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-145%3A+Support+SQL+windowing+table-valued+function > > > >> >>> [2]: > > > >> >>> > > > >> >> > > > > > > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-145-Support-SQL-windowing-table-valued-function-td45269.html > > > >> >>> > > > >> >> > > > >> > > > > > > > > > > -- > > Best, Jingsong Lee > > > -- Best, Benchao Li
[jira] [Created] (FLINK-20101) Fix the wrong documentation of FROM_UNIXTIME function
Jark Wu created FLINK-20101: --- Summary: Fix the wrong documentation of FROM_UNIXTIME function Key: FLINK-20101 URL: https://issues.apache.org/jira/browse/FLINK-20101 Project: Flink Issue Type: Bug Components: Documentation, Table SQL / API Reporter: Jark Wu Fix For: 1.12.0, 1.11.3 Attachments: image-2020-11-12-15-43-16-755.png The return value should be '1970-01-01 00:00:44' in UTC time zone. !image-2020-11-12-15-43-16-755.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
