Having looked at the proposed set of methods to remove I've noticed that
some of them are actually annotated with @Public. According to our
stability guarantees, only major releases (1.0, 2.0, etc.) can break APIs
with this annotation. Hence, I believe that we cannot simply remove them
unless the c
YufeiLiu created FLINK-18983:
Summary: Job doesn't changed to failed if close function has
blocked
Key: FLINK-18983
URL: https://issues.apache.org/jira/browse/FLINK-18983
Project: Flink
Issue Ty
Hequn Cheng created FLINK-18984:
---
Summary: Add tutorial documentation for Python DataStream API
Key: FLINK-18984
URL: https://issues.apache.org/jira/browse/FLINK-18984
Project: Flink
Issue Type
Hequn Cheng created FLINK-18985:
---
Summary: Update the Sphinx doc for Python DataStream API.
Key: FLINK-18985
URL: https://issues.apache.org/jira/browse/FLINK-18985
Project: Flink
Issue Type: S
+1 (binding)
- verified checksums and signatures
- verified that dependency changes are reflected in NOTICE/LICENSE files
- built Flink with Scala 2.12 support from sources
- Started cluster and ran example jobs, no suspicious log output
Cheers,
Till
On Mon, Aug 17, 2020 at 4:21 PM Jeff Zhang w
Chesnay Schepler created FLINK-18986:
Summary: KubernetesSessionCli creates RestClusterClient for
detached deployments
Key: FLINK-18986
URL: https://issues.apache.org/jira/browse/FLINK-18986
Proje
Hi all,
@Klou Nice write up. One comment I have is I would suggest using a
different configuration parameter name. The way I understand the
proposal the BATCH/STREAMING/AUTOMATIC affects not only the scheduling
mode but types of shuffles as well. How about `execution.mode` ? Or
`execution-runtime-
Hi Yun and Dawid,
Dawid is correct in that:
```
BATCH = pipelined scheduling with region failover + blocking keyBy
shuffles (all pointwise shuffles pipelined)
STREAM = eager scheduling with checkpointing + pipelined keyBy shuffles
AUTOMATIC = choose based on sources (ALL bounded == BATCH, STREAMIN
Chesnay Schepler created FLINK-18987:
Summary: Sort global job parameters in WebUI job configuration view
Key: FLINK-18987
URL: https://issues.apache.org/jira/browse/FLINK-18987
Project: Flink
+1 (binding)
- checked release notes ✅
- verified signatures and checksums ✅
- reviewed website PR ✅
- built an internal Flink distribution from source ✅
- built internal jobs against the staging repo ✅
- deployed a job cluster on Kubernetes and tested checkpointing ✅
- tested fix for FLINK-18902
Fabian Hueske created FLINK-18988:
-
Summary: Continuous query with LATERAL and LIMIT produces wrong
result
Key: FLINK-18988
URL: https://issues.apache.org/jira/browse/FLINK-18988
Project: Flink
+1 (non-binding)
- checksum & signatures, OK
- build from source, OK
- ran some example jobs on clusters, OK
- all pom files point to 1.10.2
- NOTICE/LICENSE files seem OK
Best,
Congxian
Till Rohrmann 于2020年8月18日周二 下午5:24写道：
> +1 (binding)
>
> - verified checksums and signatures
> - verified
Roman Khachatryan created FLINK-18989:
-
Summary: Write input and output channel state to separate files
Key: FLINK-18989
URL: https://issues.apache.org/jira/browse/FLINK-18989
Project: Flink
Roman Khachatryan created FLINK-18990:
-
Summary: Optimize reading ResultSubpartition state
Key: FLINK-18990
URL: https://issues.apache.org/jira/browse/FLINK-18990
Project: Flink
Issue Typ
Roman Khachatryan created FLINK-18991:
-
Summary: Optimize reading InputChannel state
Key: FLINK-18991
URL: https://issues.apache.org/jira/browse/FLINK-18991
Project: Flink
Issue Type: Imp
Being able to optionally fire registered processing time timers at the end
of a job would be interesting, and would help in (at least some of) the
cases I have in mind. I don't have a better idea.
David
On Mon, Aug 17, 2020 at 8:24 PM Kostas Kloudas wrote:
> Hi Kurt and David,
>
> Thanks a lot
Thanks for the updated FLIP Leonard!
In my opinion this was an improvement.
So +1 for this design.
I have just one remark regarding the terminology.
I find the term "Temporal Table without Version" somewhat confusing.
IMO, versions are the core principle of temporal tables and temporal tables
with
+1 to the updated design.
I agree with Fabian that the naming of "temporal table without version" is
a bit confusing but the actual semantics make sense to me. I think just
saying its a Flink managed lookup join makes sense.
Seth
On Tue, Aug 18, 2020 at 3:07 PM Fabian Hueske wrote:
> Thanks fo
tzxxh created FLINK-18992:
-
Summary: Table API renameColumns method annotation error
Key: FLINK-18992
URL: https://issues.apache.org/jira/browse/FLINK-18992
Project: Flink
Issue Type: Bug
C
Peng created FLINK-18993:
Summary: Invoke sanityCheckTotalFlinkMemory method incorrectly in
JobManagerFlinkMemoryUtils.java
Key: FLINK-18993
URL: https://issues.apache.org/jira/browse/FLINK-18993
Project: Fli
Peng created FLINK-18994:
Summary: There is one typo in "Set up TaskManager Memory"
Key: FLINK-18994
URL: https://issues.apache.org/jira/browse/FLINK-18994
Project: Flink
Issue Type: Improvement
Thanks Fabian and Seth for the feedback
I agree the name “temporal table without version” is less accurate because this
kind of temporal table has a latest version rather than has no version.
How about “Latest-only temporal table” ? The related concept section updated as
following:
Temporal T
Rui Li created FLINK-18995:
--
Summary: Some Hive functions fail because they need to access
SessionState
Key: FLINK-18995
URL: https://issues.apache.org/jira/browse/FLINK-18995
Project: Flink
Issue
Benchao Li created FLINK-18996:
--
Summary: Avoid disorder for time interval join
Key: FLINK-18996
URL: https://issues.apache.org/jira/browse/FLINK-18996
Project: Flink
Issue Type: Improvement
Hequn Cheng created FLINK-18997:
---
Summary: Rename type_info to result_type to make it more clear
Key: FLINK-18997
URL: https://issues.apache.org/jira/browse/FLINK-18997
Project: Flink
Issue Typ
25 matches
Mail list logo
