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:37:43 GMT

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

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

I did not say its a good example, but its a example that match the docs.
A reader may allocate resources depending on the implementation and you are creating and not
closing them - you may leak resources a reader may have allocated - that was the purpose for
that example; you can imagine every reader you want (e.g. a Buffered one which does buffer
things on disk and clear the files if you call close ...).

The actual JRE implementation used does not use such readers - but imho you should not depend
on implementation when using an interface; the JRE implementation may change and code will
leak resources in that case.
Why should a reader have a close() method if you should not call it when you are done? And
relying on GC is never a good idea when it comes to resources and you actually do not know
what *system* resources are acquired by the readers, because you can't know  what implementation
is used.

Whats the problem with calling close on that readers and tell the caller that the stream is
consumed and closed?

You said: "This is done everywhere that way." - hm what do you mean with everywhere? Usually
at least i do close all my readers which i did create.

At least it should be made clear, which was the purpose of the report, whatever solution is
accepted - close the readers or do not close them and tell the caller to close the input streams.

                
      was (Author: tkrah):
    I did not say its a good example, but its a example that match the docs.
A reader may allocate resources depending on the implementation and you are creating and not
closing them - you may leak resources a reader may have allocated - that was the purpose for
that example; you can imagine every reader you want (e.g. a Buffered one which does buffer
things on disk and clear the files if you call close ...).

The actual JRE implementation used does not use such readers - but imho you should not depend
on implementation when using an interface; the JRE implementation may change and code will
leak resources in that case.

Whats the problem with calling close on that readers and tell the caller that the stream is
consumed and closed?

You said: "This is done everywhere that way." - hm what do you mean with everywhere? Usually
at least i do close all my readers which i did create.

At least it should be made clear, which was the purpose of the report, whatever solution is
accepted - close the readers or do not close them and tell the caller to close the input streams.

                  
> 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