[ https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536418 ]
Michael McCandless commented on LUCENE-743: ------------------------------------------- {quote} If you do: {code:java} IndexReader reader1 = IndexReader.open(index1); IndexReader multiReader1 = new MultiReader(new IndexReader[] {reader1, IndexReader.open(index2)}); multiReader1.close(); {code} then today multiReader1.close() also closes reader1. That's why I consciously omitted reader1.close(). {quote} Ahh, I missed that MultiReader is allowed to close all readers that were passed into it, when it is closed. OK, let's leave reader1.close() out of the example. It's somewhat "aggressive" of MultiReader/ParallelReader to do that? If you go and use those same sub-readers in other MultiReaders then they closing of the first MultiReader will then break the other ones? I think we are forced to keep this semantics, for backwards compatibility. But I don't really think MultiReader/ParallelReader should actually be this aggressive. Maybe in the future we can add ctors for MultiReader/ParallelReader that accept a "doClose" boolean to turn this off. Anyway, it's simple to preserve this semantics with reference counting. It just means that IndexReader / MultiReader do not incref the readers they receive, and, when they are done with those readers, they must call their close(), not decref. Ie they "borrow the reference" that was passed in, rather than incref'ing their own reference, to the child readers. With that change, plus the change below, your example works fine. {quote} Consequently, if you do {code:java} IndexReader reader1 = IndexReader.open(index1); IndexReader multiReader1 = new MultiReader(new IndexReader[] {reader1, IndexReader.open(index2)}); IndexReader multiReader2 = new MultiReader(new IndexReader[] {reader1, IndexReader.open(index3)}); multiReader1.close(); {code} then multiReader2 is not usable anymore, because multiReader1.close() closes reader1. But that can be explicitly avoided by the user because it's known that multiReader1 and multiReader2 share the same reader. {quote} This is why I don't like the semantics we have today -- I don't think it's right that the multiReader1.close() breaks multiReader2. {quote} Now, with the reopen() code: {code:java} IndexReader reader1 = IndexReader.open(index1); // optimized index, reader1 is a SegmentReader IndexReader multiReader1 = new MultiReader(new IndexReader[] {reader1, IndexReader.open(index2)}); ... // modify index2 IndexReader multiReader2 = multiReader1.reopen(); // only index2 changed, so multiReader2 uses reader1 and has to increment the refcount of reader1 {code} The user gets a new reader instance from multiReader.reopen(), but can't tell which of the subreaders has been reopened and which are shared. That's why multiReader1.close() should not close reader1 in this case and we need refcounting in order to make this work. {quote} Both of these cases are easy to fix with reference counting: we just have to change ensureOpen() to assert that RC > 0 instead of closed==false. Ie, a reader may still be used as long as its RC is still non-zero. > IndexReader.reopen() > -------------------- > > Key: LUCENE-743 > URL: https://issues.apache.org/jira/browse/LUCENE-743 > Project: Lucene - Java > Issue Type: Improvement > Components: Index > Reporter: Otis Gospodnetic > Assignee: Michael Busch > Priority: Minor > Fix For: 2.3 > > Attachments: IndexReaderUtils.java, lucene-743-take2.patch, > lucene-743.patch, lucene-743.patch, lucene-743.patch, MyMultiReader.java, > MySegmentReader.java, varient-no-isCloneSupported.BROKEN.patch > > > This is Robert Engels' implementation of IndexReader.reopen() functionality, > as a set of 3 new classes (this was easier for him to implement, but should > probably be folded into the core, if this looks good). -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]