[
https://issues.apache.org/jira/browse/LUCENE-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848186#action_12848186
]
Michael McCandless commented on LUCENE-2334:
--------------------------------------------
bq. With the current implementation of IndexReader, the first close() behaves
one way (decRef()), but subsequent ones do not, which means the caller of
close() must know if this is a "simple" or "advanced" use case,
If the caller never uses incRef, then close behaves the way you expect.
bq. As written the advanced usage case means lots of extra file handles are
tied up and some day the app server dies with a "too many file handles" problem
No, if you follow the rules for advanced usage (match every incRef with a
decRef), everything should work?
bq. As you undoubtly guessed, not hypothetical - but this is the reason I even
looked at this part of the code!
Hmm OK -- can you shed some light on the specifics here?
> IndexReader.close() should call IndexReader.decRef() unconditionally ??
> -----------------------------------------------------------------------
>
> Key: LUCENE-2334
> URL: https://issues.apache.org/jira/browse/LUCENE-2334
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 3.0.1
> Reporter: Mike Hanafey
> Priority: Minor
>
> IndexReader.close() is defined:
> {code} /**
> * Closes files associated with this index.
> * Also saves any new deletions to disk.
> * No other methods should be called after this has been called.
> * @throws IOException if there is a low-level IO error
> */
> public final synchronized void close() throws IOException {
> if (!closed) {
> decRef();
> closed = true;
> }
> }
> {code}
> This means that if the refCount is bigger than one, close() does not
> actually close, but it is also true that calling close() again has no effect.
> Why does close() not simply call decRef() unconditionally? This way if
> incRef() is called each time an instance of IndexReader were handed out, if
> close() is called by each recipient when they are done, the last one to call
> close will actually close the index. As written it seems the API is very
> confusing -- the first close() does one thing, but the next close() does
> something different.
> At a minimum the JavaDoc should clarify the behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
