lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Krah (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENE-4165) HunspellDictionary - AffixFile Reader closed, Dictionary Readers left unclosed
Date Tue, 26 Jun 2012 13:54:44 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message