You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Robert Ragno (JIRA)" <ji...@apache.org> on 2011/05/04 03:15:03 UTC
[jira] [Created] (LUCENE-3067) Lucene test cases do not properly
close input and output instances
Lucene test cases do not properly close input and output instances
------------------------------------------------------------------
Key: LUCENE-3067
URL: https://issues.apache.org/jira/browse/LUCENE-3067
Project: Lucene - Java
Issue Type: Bug
Components: Build, Tests
Affects Versions: 3.1, 4.0
Reporter: Robert Ragno
Priority: Minor
The Lucene tests do not take care to close all file handles. Unless I am missing something, every single instance of Directory, IndexReader, IndexWriter, IndexSearcher, TermPositions, etc. should be wrapped with a try-finally pattern, such that the instance is always closed. Not doing so risks leaving files open, depending on the GC behavior. I believe this causes tests to fail with a "could not delete" exception, inconsistently. I at least observe this on a fast machine with Windows, where deletion is a little more sensitive to open handles. It seems dangerous and undesirable, anyway (again, unless I am missing something). I don't know of another pattern in Java that would actually be safe.
Some of these objects may just happen to be safe to let dangle in the wind, until the GC reaps, but by the contracts that really can't be allowed. The close methods need to be called to release resources.
Fixing this *appears* to alleviate the test failures, but it is hard to tell due to the nondeterministic behavior. I am reluctant to make up the whole patch if this is inaccurate - it is somewhat tedious. The classes involved can be instrumented to expose this problem. (In particular, I would imagine that the finalizer should never be reached without the close() methods being previously invoked.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3067) Lucene test cases do not properly
close input and output instances
Posted by "Uwe Schindler (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13156582#comment-13156582 ]
Uwe Schindler commented on LUCENE-3067:
---------------------------------------
Robert Ragno: You mean files outside managed "Lucene Directory" instances opened and not properly closed?
> Lucene test cases do not properly close input and output instances
> ------------------------------------------------------------------
>
> Key: LUCENE-3067
> URL: https://issues.apache.org/jira/browse/LUCENE-3067
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build, general/test
> Affects Versions: 3.1, 4.0
> Reporter: Robert Ragno
> Priority: Minor
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The Lucene tests do not take care to close all file handles. Unless I am missing something, every single instance of Directory, IndexReader, IndexWriter, IndexSearcher, TermPositions, etc. should be wrapped with a try-finally pattern, such that the instance is always closed. Not doing so risks leaving files open, depending on the GC behavior. I believe this causes tests to fail with a "could not delete" exception, inconsistently. I at least observe this on a fast machine with Windows, where deletion is a little more sensitive to open handles. It seems dangerous and undesirable, anyway (again, unless I am missing something). I don't know of another pattern in Java that would actually be safe.
> Some of these objects may just happen to be safe to let dangle in the wind, until the GC reaps, but by the contracts that really can't be allowed. The close methods need to be called to release resources.
> Fixing this *appears* to alleviate the test failures, but it is hard to tell due to the nondeterministic behavior. I am reluctant to make up the whole patch if this is inaccurate - it is somewhat tedious. The classes involved can be instrumented to expose this problem. (In particular, I would imagine that the finalizer should never be reached without the close() methods being previously invoked.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3067) Lucene test cases do not properly
close input and output instances
Posted by "Robert Ragno (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13156562#comment-13156562 ]
Robert Ragno commented on LUCENE-3067:
--------------------------------------
I believe that this is the same issue as later discovered in LUCENE-3583.
> Lucene test cases do not properly close input and output instances
> ------------------------------------------------------------------
>
> Key: LUCENE-3067
> URL: https://issues.apache.org/jira/browse/LUCENE-3067
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build, general/test
> Affects Versions: 3.1, 4.0
> Reporter: Robert Ragno
> Priority: Minor
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The Lucene tests do not take care to close all file handles. Unless I am missing something, every single instance of Directory, IndexReader, IndexWriter, IndexSearcher, TermPositions, etc. should be wrapped with a try-finally pattern, such that the instance is always closed. Not doing so risks leaving files open, depending on the GC behavior. I believe this causes tests to fail with a "could not delete" exception, inconsistently. I at least observe this on a fast machine with Windows, where deletion is a little more sensitive to open handles. It seems dangerous and undesirable, anyway (again, unless I am missing something). I don't know of another pattern in Java that would actually be safe.
> Some of these objects may just happen to be safe to let dangle in the wind, until the GC reaps, but by the contracts that really can't be allowed. The close methods need to be called to release resources.
> Fixing this *appears* to alleviate the test failures, but it is hard to tell due to the nondeterministic behavior. I am reluctant to make up the whole patch if this is inaccurate - it is somewhat tedious. The classes involved can be instrumented to expose this problem. (In particular, I would imagine that the finalizer should never be reached without the close() methods being previously invoked.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3067) Lucene test cases do not properly
close input and output instances
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028545#comment-13028545 ]
Robert Muir commented on LUCENE-3067:
-------------------------------------
Hi Robert, can you provide more information on exactly which tests you are having a problem with?
All tests wrap Directory instances via MockDirectoryWrapper.
These Directory instances are themselves registered with LuceneTestCase, and the test will fail if you do not close the Directory.
Furthermore, you cannot close these Directory instances themselves until open files are closed, as they track open files for this purpose. If you don't close all IndexReaders etc the test will fail.
> Lucene test cases do not properly close input and output instances
> ------------------------------------------------------------------
>
> Key: LUCENE-3067
> URL: https://issues.apache.org/jira/browse/LUCENE-3067
> Project: Lucene - Java
> Issue Type: Bug
> Components: Build, Tests
> Affects Versions: 3.1, 4.0
> Reporter: Robert Ragno
> Priority: Minor
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The Lucene tests do not take care to close all file handles. Unless I am missing something, every single instance of Directory, IndexReader, IndexWriter, IndexSearcher, TermPositions, etc. should be wrapped with a try-finally pattern, such that the instance is always closed. Not doing so risks leaving files open, depending on the GC behavior. I believe this causes tests to fail with a "could not delete" exception, inconsistently. I at least observe this on a fast machine with Windows, where deletion is a little more sensitive to open handles. It seems dangerous and undesirable, anyway (again, unless I am missing something). I don't know of another pattern in Java that would actually be safe.
> Some of these objects may just happen to be safe to let dangle in the wind, until the GC reaps, but by the contracts that really can't be allowed. The close methods need to be called to release resources.
> Fixing this *appears* to alleviate the test failures, but it is hard to tell due to the nondeterministic behavior. I am reluctant to make up the whole patch if this is inaccurate - it is somewhat tedious. The classes involved can be instrumented to expose this problem. (In particular, I would imagine that the finalizer should never be reached without the close() methods being previously invoked.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org