[
https://issues.apache.org/jira/browse/AVRO-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280959#comment-17280959
]
ASF subversion and git services commented on AVRO-3033:
-------------------------------------------------------
Commit 568ee67c2d0c8d62049741ae78dc91910aa1b6f2 in avro's branch
refs/heads/dependabot/nuget/lang/csharp/nunit3testadapter-3.17.0 from RyanSkraba
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=568ee67 ]
AVRO-3033: Fix flaky file descriptor test (#1078)
It looks like before fixing the bug AVRO-2286, the number of
openFilesBeforeOperation was always greater than openFilesAfterOperation. In
practice, now they're usually the same value, which is promising evidence that
there isn't a resource leak there.
The flakiness of the test comes from the fact that "something" might be fuzzing
either of them off by one. I used to see this in travis and local builds too
(but infrequently). It might be a background, system-process or an action like
garbage collection. I don't think it's instability of the machine, it's just
not as deterministic as we'd like.
> 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
> Assignee: Ryan Skraba
> Priority: Major
> Fix For: 1.11.0
>
>
> 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)
