[
https://issues.apache.org/jira/browse/AVRO-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17276446#comment-17276446
]
Ryan Skraba commented on AVRO-3033:
-----------------------------------
I've hit this flaky test as well. It seems to happen when there is activity on
the host machine that opens or closes files while the test is running.
It looks like the original bug that this is testing (AVRO-2286) always left one
file descriptor open.
A quick test on my machine, this catches about 5-10 failures over about 20
seconds.
{code:java}
@Test
public void testFlakiness() throws IOException {
int failures = 0;
for (int i = 0; i < 100000; i++)
try {
testForLeakingFileDescriptors();
} catch (AssertionError e) {
failures++;
}
assertEquals(failures, 0);
}
{code}
It's probably safe to just retry the test a few times (very few) if it happens
to fail, and consider it successful if it succeeds once. I guess it's possible
to give us a false success if one file descriptor was leaked but garbage
collection fuzzed its detection, but at least when it eventually DOES fail,
there will actually be a bug behind it.
> Java testForLeakingFileDescriptors is failing
> ---------------------------------------------
>
> Key: AVRO-3033
> URL: https://issues.apache.org/jira/browse/AVRO-3033
> Project: Apache Avro
> Issue Type: Test
> Components: java
> Reporter: Michael A. Smith
> Priority: Major
>
> See for example [this
> line|https://github.com/apache/avro/runs/1802564208#step:6:2790] in the
> actions output.
> {noformat}
> Error: Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.013
> s <<< FAILURE! - in org.apache.avro.TestDataFileReader
> Error: testForLeakingFileDescriptors(org.apache.avro.TestDataFileReader)
> Time elapsed: 0.01 s <<< FAILURE!
> java.lang.AssertionError: File descriptor leaked from new DataFileReader()
> (expected:30 actual:31)
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at
> org.apache.avro.TestDataFileReader.testForLeakingFileDescriptors(TestDataFileReader.java:63)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
