[
https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401393#comment-13401393
]
Torsten Krah edited comment on LUCENE-4165 at 6/26/12 1:54 PM:
---------------------------------------------------------------
I know the ZIPInputStream problem, but the solution here is, to use a Reader,
which does not delegate the close call to the stream, but releases all
resources which it did create itself; as you said:
... The close() call of the wrapper just delegates down, but there is no must
to call it. ...
So in general not calling close() on readers, may leak resources if they did
acquire extra ones beside the stream they take (which is up to the actual
implementation used) - so in general its good to close them; there are actual
some implementations of cause, which are a PITA to use if you actually call
"close" (e.g. the ZIPInputStream problem)- but thats another problem.
Ok back to topic :-D:
I am going to add a patch for trunk and branch which does remove the
reader.close() call and add a javadoc comment to the constructors, that the
streams provided MUST be closed by the caller, right?
was (Author: tkrah):
I know the ZIPInputStream problem, but the solution here is, to use a
Reader, which does not delegate the close call to the stream, but releases all
resources which it did create itself; as you said:
... The close() call of the wrapper just delegates down, but there is no must
to call it. ...
So in general not calling close() on readers, may leak resources if they did
acquire extra ones beside the stream they take (which is up to the actual
implementation used) - so in general its good to close them; there are actual
some implementations of cause, which are a PITA to use if you actually call
"close" (e.g. the ZIPInputStream problem)- but thats another problem.
Ok back to topic :-D:
I am going to add a patch for trunk and branch which does remove the
reader.close() call and add a javadoc comment to the constructors, what the
streams provided MUST be closed by the user, right?
> HunspellDictionary - AffixFile Reader closed, Dictionary Readers left unclosed
> ------------------------------------------------------------------------------
>
> Key: LUCENE-4165
> URL: https://issues.apache.org/jira/browse/LUCENE-4165
> Project: Lucene - Java
> Issue Type: Bug
> Components: modules/analysis
> Affects Versions: 3.6
> Environment: Linux, Java 1.6
> Reporter: Torsten Krah
> Priority: Minor
> Attachments: lucene_36.patch, lucene_trunk.patch
>
>
> The HunspellDictionary takes an InputStream for affix file and a List of
> Streams for dictionaries.
> Javadoc is not clear about i have to close those stream myself or the
> Dictionary constructor does this already.
> Looking at the code, at least reader.close() is called when the affix file is
> read via readAffixFile() method (although closing streams is not done in a
> finally block - so the constructor may fail to do so).
> The readDictionaryFile() method does miss the call to close the reader in
> contrast to readAffixFile().
> So the question here is - have i have to close the streams myself after
> instantiating the dictionary?
> Or is the close call only missing for the dictionary streams?
> Either way, please add the close calls in a safe manner or clarify javadoc so
> i have to do this myself.
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
