-1
We're testing this version on batch jobs with large (600~1000) parallelisms
and the following exception messages appear with high frequency:
2021-04-27 21:27:26
org.apache.flink.util.FlinkException: An OperatorEvent from an
OperatorCoordinator to a task was lost. Triggering task failover to en
+1 (binding)
- started cluster, ran example job on macos
- sources look fine
- Eyeballed the diff:
https://github.com/apache/flink/compare/release-1.12.2...release-1.12.3-rc1.
According to "git diff release-1.12.2...release-1.12.3-rc1 '*.xml'", there
was only one external dependency change (snappy
ranqiqiang created FLINK-22499:
--
Summary: JDBC sink table-api support "sink.parallelism" ?
Key: FLINK-22499
URL: https://issues.apache.org/jira/browse/FLINK-22499
Project: Flink
Issue Type: Ne
flink lib jar:
flink taskmanager log:
hive orc table create ddl:
create table xxx ... stored as orc
flink java class, Join the hive Orc table and Kafka stream data:
bsTableEnv.executeSql("my sql is join");flink pom.xml in the attachment.
I convert the file type to textfile type to run. But
Carl created FLINK-22498:
Summary: cast the primary key for source table that has a decimal
primary key as string, and then insert into a kudu table that has a string
primary key throw the exception : UpsertStreamTableSink requires that Table has
a full
ChangjiGuo created FLINK-22497:
--
Summary: When using DefaultRollingPolicy in StreamingFileSink, the
file will be finished delayed
Key: FLINK-22497
URL: https://issues.apache.org/jira/browse/FLINK-22497
P
+1 (non-binding)
- verified checksum and signature
- built from source
- executed example jobs with standalone / native kubernetes deployments,
nothing unexpected
- reviewed release announcement pull request
Thank you~
Xintong Song
On Tue, Apr 27, 2021 at 10:50 PM Piotr Nowojski
wrote:
> +1
Thanks for the detailed explanations! Regarding the usage of timeout, now I
agree that it is better to remove per-test timeouts because it helps
make our testing results more reliable and consistent.
My previous concern is that it might not be a good idea to intentionally
let the test hang in AZP
Guowei Ma created FLINK-22496:
-
Summary:
ClusterEntrypointTest.testCloseAsyncShouldBeExecutedInShutdownHook failed
Key: FLINK-22496
URL: https://issues.apache.org/jira/browse/FLINK-22496
Project: Flink
Just to add to Dong Lin's list of cons of allowing timeout:
- Any timeout value that you manually set is arbitrary. If it's set too
low, you get test instabilities. What too low means depends on numerous
factors, such as hardware and current utilization (especially I/O). If you
run in VMs and the V
Till Rohrmann created FLINK-22495:
-
Summary: Document how to use the reactive mode on K8s
Key: FLINK-22495
URL: https://issues.apache.org/jira/browse/FLINK-22495
Project: Flink
Issue Type: Im
I think we do capture the INFO logs of the test runs on AZP.
I am also not sure whether we really caught slow tests with Junit's timeout
rule before. I think the default is usually to increase the timeout to make
the test pass. One way to find slow tests is to measure the time and look
at the outl
Matthias created FLINK-22494:
Summary: Avoid discarding checkpoints in case of failure
Key: FLINK-22494
URL: https://issues.apache.org/jira/browse/FLINK-22494
Project: Flink
Issue Type: Improveme
+1 (binding)
- Verified checksums and signatures
- Reviewed the website PR
- Built from sources
- verified dependency version upgrades and updates in NOTICE files compared to
1.12.2
- started cluster and run WordCount example in BATCH mode and everything looked
good
On 23/04/2021 23:52, Arvid H
+1 (binding)
I'm not aware of any release blockers. Me and my colleagues have checked
quite extensively this release for correctness of the unaligned
checkpoints, finally nailing down the two remaining known bugs.
I have manually checked the WebUI with it's new back-pressure
monitoring tool. One b
Dawid Wysakowicz created FLINK-22493:
Summary: AdaptiveSchedulerITCase found unexpected files
Key: FLINK-22493
URL: https://issues.apache.org/jira/browse/FLINK-22493
Project: Flink
Issue
There is one more point that may be useful to consider here.
In order to debug deadlock that is not easily reproducible, it is likely
not sufficient to see only the thread dump to figure out the root cause. We
likely need to enable the INFO level logging. Since AZP does not provide
INFO level logg
Just to make sure I understand the proposal correctly: is the proposal to
disallow the usage of @Test(timeout=...) for Flink Junit tests?
Here is my understanding of the pros/cons according to the discussion so
far.
Pros of allowing timeout:
1) When there are tests that are unreasonably slow, it
Dawid Wysakowicz created FLINK-22492:
Summary: KinesisTableApiITCase with wrong results
Key: FLINK-22492
URL: https://issues.apache.org/jira/browse/FLINK-22492
Project: Flink
Issue Type:
Leon Hao created FLINK-22491:
Summary: JdbcBatchingOutputFormat checks size of buffer in
TableBufferReducedStatementExecutor
Key: FLINK-22491
URL: https://issues.apache.org/jira/browse/FLINK-22491
Project
ZRCoder created FLINK-22490:
---
Summary: YarnApplicationClusterEntryPoint does not pass
configuration parameters
Key: FLINK-22490
URL: https://issues.apache.org/jira/browse/FLINK-22490
Project: Flink
David Anderson created FLINK-22489:
--
Summary: subtask backpressure indicator shows value for entire job
Key: FLINK-22489
URL: https://issues.apache.org/jira/browse/FLINK-22489
Project: Flink
Assuming that not many tests deadlock I think it should be fine to simply
let the build process deadlock. Even if multiple tests fail consistently,
then one would see them one after another. That way we wouldn't have to
build some extra tooling. Moreover, the behaviour would be consistent on
the lo
23 matches
Mail list logo
