[ 
https://issues.apache.org/jira/browse/LUCENE-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shai Erera updated LUCENE-3144:
-------------------------------

    Attachment: LUCENE-3144.patch

Patch against 3x, adds safeMaybe() versions to MockIOWrapper which closes the 
underlying IO on exception.

However, TestIndexWriterExceptions.testDocumentsWriterAbort still leaves open 
file handles. On Windows, I put a break point in several places throughout the 
test, and even after IW.close() is called, I still see that .tii, .tis and .frq 
are being kept by the Java process.

Is it a bug that we don't close them (in actual code, not test)? They have no 
references in MockDirWrapper ...

> MockIndexOutputWrapper should close() if 
> dir.maybeThrowDeterminsticException() throws an exception
> --------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3144
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3144
>             Project: Lucene - Java
>          Issue Type: Test
>          Components: general/test
>            Reporter: Shai Erera
>            Assignee: Shai Erera
>            Priority: Minor
>             Fix For: 3.2, 4.0
>
>         Attachments: LUCENE-3144.patch
>
>
> MockIndexOutputWrapper checks in various places 
> dir.maybeThrowDeterminsticException(). If an exception is actually thrown, 
> the IndexOutput is not closed, and therefore file handles remain open which 
> prevent cleaning up directories on Windows (and LTC.afterClass prints nasty 
> stack traces).
> We should wrap every call with a try-catch -- if an exception is thrown, we 
> should close() the underlying stream. This should be done to backwards too 
> (in 3x).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to