[ 
https://issues.apache.org/jira/browse/AVRO-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280960#comment-17280960
 ] 

ASF subversion and git services commented on AVRO-2286:
-------------------------------------------------------

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.

> DataFileReader leaks file descriptor on exception during construction
> ---------------------------------------------------------------------
>
>                 Key: AVRO-2286
>                 URL: https://issues.apache.org/jira/browse/AVRO-2286
>             Project: Apache Avro
>          Issue Type: Bug
>          Components: java
>    Affects Versions: 1.8.2
>            Reporter: Holger Fleischmann
>            Assignee: Martin Jubelgas
>            Priority: Major
>             Fix For: 1.9.0
>
>         Attachments: DataFileReaderCloseBug.java
>
>
> The constructor {{DataFileReader(File, DatumReader)}} does not close the 
> already opened file again when it throws an exception. This leads to a leaked 
> file descriptor and especially to not being able to delete the still open 
> invalid file then (at least on Windows).
> This case is important when Avro files may be truncated on write, e.g. due to 
> a hard shutdown, and the application must be able to recover from such a 
> situation on the next restart.
> Please see the attached file {{DataFileReaderCloseBug.java}} to reproduce the 
> problem.
> I did not find that problem in Jira/mailing lists. Thanks for your help in 
> advance :)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to