You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Torsten Krah (JIRA)" <ji...@apache.org> on 2012/06/26 10:00:46 UTC
[jira] [Created] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Torsten Krah created LUCENE-4165:
------------------------------------
Summary: 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
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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403037#comment-13403037 ]
Chris Male commented on LUCENE-4165:
------------------------------------
Thanks for doing that Torsten. Would it be possible to make a version that doesn't change IOUtils but instead just catches the useless Exception? 3.6.1 is just a bug fix so I'd rather not change anything unnecessary.
> 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-4156-trunk.patch, LUCENE_4156_36.patch, 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ 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:30 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.
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.
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401307#comment-13401307 ]
Torsten Krah edited comment on LUCENE-4165 at 6/26/12 11:49 AM:
----------------------------------------------------------------
It -would- should be sufficient.
Only reason i did was, that fd is freed asap it is not needed anymore to get rid of it, just in case processing of the others may take time.
But its a more theoretical scenario, because file descriptors should not be that "low" to make a real world difference here.
Should i'll provide new patches?
Obsoleted comment, see next one from me.
was (Author: tkrah):
-deleted-
It should be sufficient.
Only reason i did was, that fd is freed asap it is not needed anymore to get rid of it, just in case processing of the others may take time.
But its a more theoretical scenario, because file descriptors should not be that "low" to make a real world difference here.
Should i'll provide new patches?
-deleted-
> 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
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated LUCENE-4165:
---------------------------------
Attachment: (was: LUCENE_4156_36.patch)
> 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-4156-trunk.patch, LUCENE_4156_36.patch, 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ 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:38 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 and because of that, you don't even know for sure if "finalize" does call close.
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.
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.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401308#comment-13401308 ]
Chris Male commented on LUCENE-4165:
------------------------------------
That'd be great if you could since I think it is cleaner for them to be closed in one place.
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401307#comment-13401307 ]
Torsten Krah edited comment on LUCENE-4165 at 6/26/12 11:48 AM:
----------------------------------------------------------------
-deleted-
It should be sufficient.
Only reason i did was, that fd is freed asap it is not needed anymore to get rid of it, just in case processing of the others may take time.
But its a more theoretical scenario, because file descriptors should not be that "low" to make a real world difference here.
Should i'll provide new patches?
-deleted-
was (Author: tkrah):
It would be sufficient.
Only reason i did was, that fd is freed asap it is not needed anymore to get rid of it, just in case processing of the others may take time.
But its a more theoretical scenario, because file descriptors should not be that "low" to make a real world difference here.
Should i'll provide new patches?
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401312#comment-13401312 ]
Torsten Krah commented on LUCENE-4165:
--------------------------------------
Just did think about it again and would prefer to close the readers explicitly too.
A Reader may internally acquire other resources (byte buffers etc.) which must/should be released too.
Calling close() on the reader should imho be done too - do you agree with me?
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401350#comment-13401350 ]
Chris Male commented on LUCENE-4165:
------------------------------------
So we should close any Readers we internally create (such as in readDictionaryFile()) but leave the InputStreams that have been passed in?
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401361#comment-13401361 ]
Chris Male commented on LUCENE-4165:
------------------------------------
Okay, makes sense. Then we need to pull out the close in readAffixFile and document that we don't close anything (even if it is the general Java contract, will still be helpful for users to know).
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401369#comment-13401369 ]
Chris Male commented on LUCENE-4165:
------------------------------------
Did you actually run into any problems (lack of fds, OOMs) Torsten? or was it just the lack of documentation that made you aware of the issue?
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401367#comment-13401367 ]
Torsten Krah edited comment on LUCENE-4165 at 6/26/12 1:00 PM:
---------------------------------------------------------------
Hm thats correct - but than the Reader should imho be closed anyway and the callee must be aware (via docs) that in any failure case, he should cleanup the streams provided or he may leak some fd.
was (Author: tkrah):
Hm that correct - but than the Reader should imho be closed anyway and the callee must be aware (via docs) that in any failure case, he should cleanup the streams provided or he may leak some fd.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401397#comment-13401397 ]
Uwe Schindler commented on LUCENE-4165:
---------------------------------------
+1, Yes.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401377#comment-13401377 ]
Chris Male commented on LUCENE-4165:
------------------------------------
Okay then I think a reasonable solution would be to remove the close from readAffixFile and document then it is the callers responsibility to close the 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401364#comment-13401364 ]
Uwe Schindler commented on LUCENE-4165:
---------------------------------------
We should document it, that would be good.
The example with the ZIPInputStream is the number one example, why a method should not close streams passed to it :-) Otherwise you need horrible things like "CloseShieldInputStream" (as used by TIKA) to prevent closing for the ZIP file case.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401307#comment-13401307 ]
Torsten Krah commented on LUCENE-4165:
--------------------------------------
It would be sufficient.
Only reason i did was, that fd is freed asap it is not needed anymore to get rid of it, just in case processing of the others may take time.
But its a more theoretical scenario, because file descriptors should not be that "low" to make a real world difference here.
Should i'll provide new patches?
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401365#comment-13401365 ]
Torsten Krah commented on LUCENE-4165:
--------------------------------------
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
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated LUCENE-4165:
---------------------------------
Attachment: LUCENE_4156_36.patch
Updated patch for 36 branch which does handle StemFactory closing.
Ported IOUtils change from trunk to branch (IOException removed from throws declaration).
> 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-4156-trunk.patch, LUCENE_4156_36.patch, 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401367#comment-13401367 ]
Torsten Krah commented on LUCENE-4165:
--------------------------------------
Hm that correct - but than the Reader should imho be closed anyway and the callee must be aware (via docs) that in any failure case, he should cleanup the streams provided or he may leak some fd.
> 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
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated LUCENE-4165:
---------------------------------
Attachment: LUCENE_4156_36.patch
Updated patch, removed IOUtils change, catch useless Exception.
> 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-4156-trunk.patch, LUCENE_4156_36.patch, 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401359#comment-13401359 ]
Uwe Schindler commented on LUCENE-4165:
---------------------------------------
If you close the Reader it automatically closes all underlying streams (see docs). So: No, you simply wrap any readers around in your code and let GC do its work. Reader dont allocate any resources like file handles whatever. InputStreamReader just wraps a CharsetDecoder on top. Buffers it allocates will be freed by GC.
So just take the IS as got from caller, do something with it (e.g. wrap a Reader on top) and then return method without doing anything. Closing any wrapped readers would break the contract. If the caller closes the InputStream he releases resources.
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401247#comment-13401247 ]
Torsten Krah commented on LUCENE-4165:
--------------------------------------
Yeah i can do so. Against trunk only or branch-3.6 too?
> 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
>
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401366#comment-13401366 ]
Robert Muir commented on LUCENE-4165:
-------------------------------------
{quote}
Than to not take InputStreams as arguments but use a Reader and document that the callee must call close on that reader.
{quote}
I think the challenge is the caller does not know how to supply a reader as the encoding is specified in the .aff file.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401386#comment-13401386 ]
Uwe Schindler commented on LUCENE-4165:
---------------------------------------
-1, don't close InputStreams. We do this *nowhere* in Lucene.
bq. 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.
I am talking about libraries. Of course the end user code closes the underlying stream. And with the filter-reader contract you are wrong. Reader's and InputStream are a Decorator-Pattern API. The close() call of the wrapper just delegates down, but there is no must to call it.
bq. Whats the problem with calling close on that readers and tell the caller that the stream is consumed and closed?
See my example with ZIPInputStream. If you close the Reader on top, it will close the ZIPInputStream. You have no chance to read the next ZIP-file entry. There are more examples like this.
The design of the Lucene TokenStream API also follows the decorator pattern, the same applies for this one.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401375#comment-13401375 ]
Torsten Krah commented on LUCENE-4165:
--------------------------------------
Not yet.
It was a pure lack of documentation and as Tika got leaking descriptors in v0.9 which really hurt me, i thought it might be a good idea to find a solution :-).
I am using a custom Tokenizer and wanted to use the HunspellDictionary and did not know if i have to close the streams or not because docs does not tell.
Looking at the code it does close the affix reader, but does not close the dicionary ones - so here is at least a gap ;-).
Using "lsof" you can see the affic file descriptor vanishing and the dictionary one still there (because i did not close the stream), so it does leak yet.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401381#comment-13401381 ]
Torsten Krah commented on LUCENE-4165:
--------------------------------------
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?
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401259#comment-13401259 ]
Chris Male commented on LUCENE-4165:
------------------------------------
Trunk and 3.6 would be fantastic since this is really a bug fix so we'll get it into 3.6.1.
> 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
>
> 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
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated LUCENE-4165:
---------------------------------
Attachment: (was: lucene_trunk.patch)
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401312#comment-13401312 ]
Torsten Krah edited comment on LUCENE-4165 at 6/26/12 11:46 AM:
----------------------------------------------------------------
Just did think about it again and would prefer to close the readers explicitly too.
A Reader may internally acquire other resources (byte buffers etc.) which must/should be released too (e.g. have a look at: com.sun.org.apache.xerces.internal.impl.io.UTF8Reader).
Calling close() on the reader should imho be done too - do you agree with me?
was (Author: tkrah):
Just did think about it again and would prefer to close the readers explicitly too.
A Reader may internally acquire other resources (byte buffers etc.) which must/should be released too.
Calling close() on the reader should imho be done too - do you agree with me?
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401398#comment-13401398 ]
Chris Male commented on LUCENE-4165:
------------------------------------
+1
> 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
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated LUCENE-4165:
---------------------------------
Attachment: lucene_36.patch
lucene_trunk.patch
Updated patches:
1. removed reader.close() call in readAffixFile() function.
2. Add comment at ctors and arguments to make clear that caller has to close the streams and that the ctor does not close them.
3. Test modified to check its actually not closed.
4. Added 2 close calls on the streams in trunk patch for the Test.
> 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_36.patch, lucene_trunk.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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401401#comment-13401401 ]
Uwe Schindler commented on LUCENE-4165:
---------------------------------------
bq. to use a Reader, which does not delegate the close call to the stream
Java Readers do this. The only workaround is e.g. TIKA's CloseShieldInputStream. If you wrap it between the original stream and your InputStreamReader on top, then you can call close on the InputStreamReader.
About the misunderstanding: The counterpart for close() is the ctor, and close() closes the "underlying" "opened" resource (this is what the docs says). This resource is the stream and nothing else. If you call close on a decorator (like InputStreamReader, BufferedInputStrea), the close call closes the underlying "opened" resource. It talks about nothing else.
As I said, XERCES UTF8Reader is already horribly broken, it violates Unicode specs and lots of other stuff + it is horribly slow, so its a bad example. If it allocates ThreadLocals, there is no need / requirement to release them on close(). Close() should only close the underlying resource, not any helpers around.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401426#comment-13401426 ]
Torsten Krah commented on LUCENE-4165:
--------------------------------------
Last 2 cents about the misunderstanding:
Doc says: "Closes the stream and releases any system resources associated with it.".
May be read like this:
1. "it" may actually mean the stream here -> "Closes the stream and releases any system resources associated with the stream."
2. "it" just meaning the object (reader) itself -> "Closes the stream and releases any system resources associated with the reader."
Both is possible (is it?) and to me 2. would be more common, because @ variant 1. you do not know, if "close" on the stream does really release any system resources (this is up to the input streams close method, e.g. take the CloseShieldInputStream.) - so if 1. should be the only one meaning of the docs, they are promising things, which they can't enforce ;-).
But i guess i have to look at english grammer again (long long ago ...) - maybe this is really clear here how it must be understand - if 1. is the only possible one from a language perspective one, than it should imho read more like this:
"Does call close on the Stream." - not more, because you do not know if any system resources are freed; this should be documented at the close() method of the actual InputStream documentation used.
Back to topic: I'll provide those patches asap.
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ 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:28 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.
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.
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?
> 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
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated LUCENE-4165:
---------------------------------
Attachment: (was: lucene_36.patch)
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401232#comment-13401232 ]
Chris Male edited comment on LUCENE-4165 at 6/26/12 8:10 AM:
-------------------------------------------------------------
You're right, we should clean up the Streams and make it clear. Do you want to put together a patch which addresses this?
was (Author: cmale):
You're right, we should clean up the Streams and make it clear.
> 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
>
> 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
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated LUCENE-4165:
---------------------------------
Attachment: lucene_36.patch
lucene_trunk.patch
- Patch against trunk and 3.6.
- Resources are closed asap.
- Finally block in constructor added to be sure resources are closed too if an exception is hit before resources are processed.
- Test modified to check if close() was called on the provided streams after the Dictionary constructor was called.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401393#comment-13401393 ]
Torsten Krah commented on LUCENE-4165:
--------------------------------------
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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401232#comment-13401232 ]
Chris Male commented on LUCENE-4165:
------------------------------------
You're right, we should clean up the Streams and make it clear.
> 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
>
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401323#comment-13401323 ]
Chris Male commented on LUCENE-4165:
------------------------------------
Yes you're quite right actually. Okay we'll go with closing them in both places.
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401379#comment-13401379 ]
Uwe Schindler commented on LUCENE-4165:
---------------------------------------
bq. 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.
LOOOOL :-) UTF8Reader of Xerces is broken, so don't take this one as example. It should go away, especially it is slower (like Jettys broken readers, too) than recent Java ones. In times of Java 1.1 there was a speed improvement, but not any more.
The Readers we wrap around the InputStream are standard Java readers (InputStreamReader) and we really don't need to close them. This is done everywhere that way. BufferedReader (if needed), also needs no close. No broken ThreadLocals, nothing, just plain GC. So please don't do any crazy stuff here.
The only thing that takes *system* resources like FDs may be the InputStream from a File or ZIP file. And those will be closed by the caller.
We should just document that the InputStream is not closed. There is nothing to worry about. We had a similar discussion already in the past with the Readers passed to Fields.
Uwe
> 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401343#comment-13401343 ]
Uwe Schindler commented on LUCENE-4165:
---------------------------------------
Two things:
- In Lucene we have a variant of the Java 7 close with resources logic. It is (including examples) in the utility package (IOUtils). We should use this, as it correctly handles special cases like supressing Exceptions occuring on close(). It also ensures, *all* resources are closed.
- from my perspective / in my opinion: the general contract in Java is, that methods getting streams or readers don't close. This is e.g. important if you have the stuff in a ZIP file and read it with ZIPInputStream. If you close that reader, you cannot read the other files in the archive anymore. So I would prefer to let the user close the files. Behavior in APIs is different for methods taking file names, of course. They close their internal streams. We also fixed other places in Lucene to respect this contract. E.g., IndexWriter does not close readers from Field instances.
> 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
[jira] [Comment Edited] (LUCENE-4165) HunspellDictionary -
AffixFile Reader closed, Dictionary Readers left unclosed
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401386#comment-13401386 ]
Uwe Schindler edited comment on LUCENE-4165 at 6/26/12 1:47 PM:
----------------------------------------------------------------
-1, don't close InputStreams. We do this *nowhere* in Lucene (of course we close streams, but only if *we* open them. Wrapping is *not* opening, it's just decorating the underlying).
bq. 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.
I am talking about libraries. Of course the end user code closes the underlying stream. And with the filter-reader contract you are wrong. Reader's and InputStream are a Decorator-Pattern API. The close() call of the wrapper just delegates down, but there is no must to call it.
bq. Whats the problem with calling close on that readers and tell the caller that the stream is consumed and closed?
See my example with ZIPInputStream. If you close the Reader on top, it will close the ZIPInputStream. You have no chance to read the next ZIP-file entry. There are more examples like this.
The design of the Lucene TokenStream API also follows the decorator pattern, the same applies for this one.
was (Author: thetaphi):
-1, don't close InputStreams. We do this *nowhere* in Lucene.
bq. 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.
I am talking about libraries. Of course the end user code closes the underlying stream. And with the filter-reader contract you are wrong. Reader's and InputStream are a Decorator-Pattern API. The close() call of the wrapper just delegates down, but there is no must to call it.
bq. Whats the problem with calling close on that readers and tell the caller that the stream is consumed and closed?
See my example with ZIPInputStream. If you close the Reader on top, it will close the ZIPInputStream. You have no chance to read the next ZIP-file entry. There are more examples like this.
The design of the Lucene TokenStream API also follows the decorator pattern, the same applies for this one.
> 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
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Male updated LUCENE-4165:
-------------------------------
Attachment: LUCENE-4156-trunk.patch
Updated version of trunk patch which closes the InputStreams created in Solr's HunspellStemFilterFactory.
> 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-4156-trunk.patch, 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
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
Reader closed, Dictionary Readers left unclosed
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401284#comment-13401284 ]
Chris Male commented on LUCENE-4165:
------------------------------------
Isn't it sufficient to have the streams closed in the finally block of the constructor? Is there any reason we need to close them in readAffix and readDictionary as well?
> 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