[
https://issues.apache.org/jira/browse/FLINK-22097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17316830#comment-17316830
]
Shengkai Fang commented on FLINK-22097:
---------------------------------------
The failed test is mainly to test the view thread has the ability to exit
gracefully when users(main thread) interrupt the view thread.
We have 3 threads in the test: main thread, view thread and refresh thread.
- The main thread has the resource {{Terminal}} and uses the the resource to
create the view thread. When the view thread starts, it set the interrupt flag
on the view thread and *close* the {{Terminal}} until view thread exits
- When view thread start, it start the refresh thread and monitors the user
input. In the test, it only monitors interrput signal. When get the signal, it
mark the flag {{isRunning}} of the refresh thread {{false}} and notify the
refresh thread.
- The refresh thread is used to fetch the data from the remote periodically
and display the results on {{Terminal}}. When exits, the refresh thread will
invoke the \{{Executor.cancelQuery}} and count down the {{cancellation}}.
The reason why we can NPE is because when view thread exits, it only notifies
the refresh thread instead of waiting for the refresh thread exits. It's
possible
# the view thread notifies the refresh thread
# the refresh thread wakes up and prepares to display the result on the
terminal
# the view thread exits
# the main thread finds the view thread exit and closes the resource
# the refresh thread gets NPE
# the main thread find the {{cancellation}} is not as same as the expected
Therefore, we should request the view thread wait for the refresh thread exit.
To reproduce the bug, we can request the refresh thread sleep 1 seconds before
display.
> testChangelogResultViewClearEmptyResult fail.
> ---------------------------------------------
>
> Key: FLINK-22097
> URL: https://issues.apache.org/jira/browse/FLINK-22097
> Project: Flink
> Issue Type: Bug
> Components: Table SQL / Client
> Affects Versions: 1.13.0
> Reporter: Guowei Ma
> Assignee: Shengkai Fang
> Priority: Major
> Labels: test-stability
> Fix For: 1.13.0
>
>
> https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=15968&view=logs&j=b2f046ab-ae17-5406-acdc-240be7e870e4&t=93e5ae06-d194-513d-ba8d-150ef6da1d7c&l=8539
> {code:java}
> Exception in thread "Thread-9" java.lang.NullPointerException
> at
> org.apache.flink.table.client.cli.CliClient.isPlainTerminal(CliClient.java:181)
> at
> org.apache.flink.table.client.cli.CliClient.clearTerminal(CliClient.java:169)
> at org.apache.flink.table.client.cli.CliView.display(CliView.java:191)
> at
> org.apache.flink.table.client.cli.CliChangelogResultView.display(CliChangelogResultView.java:101)
> at
> org.apache.flink.table.client.cli.CliResultView$RefreshThread.run(CliResultView.java:267)
> {code}
> {code:java}
> java.lang.AssertionError: Invalid number of cancellations.
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.flink.table.client.cli.CliResultViewTest.testResultViewClearResult(CliResultViewTest.java:117)
> at
> org.apache.flink.table.client.cli.CliResultViewTest.testChangelogResultViewClearEmptyResult(CliResultViewTest.java:73)
> 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.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.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)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
