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