[ https://issues.apache.org/jira/browse/LUCENE-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724131#action_12724131 ]
Shai Erera commented on LUCENE-1707: ------------------------------------ bq. But, if refCount hits 0 and closed is false then there's some bug lurking (in the app code or the Lucene code)? Ie, someone did an extra decRef. I'd rather things fail then hide the bug in that case. By that you're saying that calling decRef() and then close() is wrong, which I agree, but still possible. Why not protect against it, by setting closed=true in decRef() if refCount drops to 0? What good does "not hiding that bug" do? Currently the tests pass whether I protect against it or not, so our code works fine (no surprises here). But I just think that decRef() and close() are public, which doesn't prevent anyone from calling them in whatever order one wants :). If you don't think it's necessary to protect against it, I'll post a patch w/o it. > Don't use ensureOpen() excessively in IndexReader and IndexWriter > ----------------------------------------------------------------- > > Key: LUCENE-1707 > URL: https://issues.apache.org/jira/browse/LUCENE-1707 > Project: Lucene - Java > Issue Type: Improvement > Components: Index > Reporter: Shai Erera > Fix For: 2.9 > > Attachments: LUCENE-1707.patch > > > A spin off from here: > http://www.nabble.com/Excessive-use-of-ensureOpen()-td24127806.html. > We should stop calling this method when it's not necessary for any internal > Lucene code. Currently, this code seems to hurt properly written apps, > unnecessarily. > Will post a patch soon -- 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