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:00:45 GMT

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

Torsten Krah edited comment on LUCENE-4165 at 6/26/12 12:58 PM:
----------------------------------------------------------------

Just my 2 cents:

But GC may or may not happend and you will run out of file descriptors sooner or later. You
can't rely on GC to kick in and clean up and the resources may be gone already (fd run out
e.g.).

ZIPInputstream is a good example, the Inflater instance there does use non heap memory and
is only freed if "inflater.end()" is called. This will be done via finalize - but you are
going to see OOMException before, because you have enough heap, but the memory used by the
inflater is full.

And creating Readers and not closing them is imho not good either, e.g. take a look at: com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.
No finalize there, if you do not call close on that reader, the ThreadLocal allocated does
leak - imho if you create readers, you should close them.

In this case the readers are not allocating extra stuff so closing the streams can be done
by the user, but imho not closing internally created readers is not good. Than to not take
InputStreams as arguments but use a Reader and document that the callee must call close on
that reader.

                
      was (Author: tkrah):
    Just my 2 cents:

But GC may or may not happend and you will run out of file descriptors sooner or later. You
can't rely on GC do kick in and resources may be gone already.
And creating Readers and not closing them is imho not good either, e.g. take a look at: com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.
No finalize there, if you do not call close on that reader, the ThreadLocal allocated does
leak - imho if you create readers, you should close them.

In this case the readers are not allocating extra stuff so closing the streams can be done
by the user, but imho not closing internally created readers is not good. Than to not take
InputStreams as arguments but use a Reader and document that the callee must call close on
that reader.

                  
> 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