Funny, we're just having a similar discussion on LUCENE-1707. I think the purpose of closed is to save against calling close() twice w/o "knowing any better". I.e, IndexWriter.ReadersPool's release() both call decRef() (to decrease its own ref) and close() to decrease the caller's. But then the caller might want to call close() too, since it doesn't know the reader has been closed. I can imagine other situations like that. TestIndexReaderReopen will hit it, and fail (that's what I tried in 1707).
Doesn't reopen increase the refCount already? why do you call incRef()? Shai On Thu, Jun 25, 2009 at 10:09 PM, Yonik Seeley <[email protected]>wrote: > Are the semantics of close() really correct when reopen() is used? > > public final synchronized void close() throws IOException { > if (!closed) { > decRef(); > closed = true; > } > } > > Solr has the following code: > IndexReader newReader = currentReader.reopen(); > if (newReader == currentReader) { > currentReader.incRef(); > } > > reopen() used to return the same instance if no changes had been made > - that makes sense. > But then of you do a close on both the currentReader and newReader, > only one decRef() will be called! > > The reopen() javadoc suggests this has not changed: > * If the index has not changed since this instance was (re)opened, then > this > * call is a NOOP and returns this instance. > > Seems like the "closed" variable just be eliminated completely? > Throwing an exception on too many closes (rather than silently > ignoring) would probably be doing people a favor. > > -Yonik > http://www.lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
