Hi Thomas,
Regarding [2], it has more detail infos in the Jira description
(https://issues.apache.org/jira/browse/FLINK-16404).
I can also give some basic explanations here to dismiss the concern.
1. In the past, the following buffers after the barrier will be cached on
downstream side before
+1
- started cluster and ran some examples, verified web ui and log output,
nothing unexpected, except ChangelogSocketExample which has been reported
[2] by Dawid.
- started cluster to run e2e SQL queries with millions of records with
Kafka, MySQL, Elasticsearch as sources/lookup/sinks. Works well
Hi Zhijiang,
Could you please point me to more details regarding: "[2]: Delay send the
following buffers after checkpoint barrier on upstream side until barrier
alignment on downstream side."
In this case, the downstream task has a high average checkpoint duration
(~30s, sync part). If there was
+1 (non-binding) % some NOTICE files missing
I found some projects do not contain NOTICE file (I'm not sure these
projects do not need NOTICE file or the NOTICE file is missing. I report
the findings here.).
The pom.xml change is based on the compare between
release-1.10.0..release-1.11-RC4[1], t
Jark Wu created FLINK-18486:
---
Summary: Add documentation for the '%' modulus function
Key: FLINK-18486
URL: https://issues.apache.org/jira/browse/FLINK-18486
Project: Flink
Issue Type: Task
+1 (non-binding)
- rolled out to thousands of router jobs in our test env
- tested with a large-state job. Did simple resilience and
checkpoint/savepoint tests. General performance metrics look on par.
- tested with a high-parallelism stateless transformation job. General
performance metrics look
Hi Thomas,
Thanks for the further update information.
I guess we can dismiss the network stack changes, since in your case the
downstream and upstream would probably be deployed in the same slot bypassing
the network data shuffle.
Also I guess release-1.11 will not bring general performance r
