[
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 1:01 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 may have
enough heap and GC decides not to collect your ZIS instance, 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 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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
