Created: (LUCENE-743) IndexReader.reopen()

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536409 ] 

Michael McCandless commented on LUCENE-743:
-------------------------------------------

It's not nearly this complex (we don't need two ref counts).
If we
follow the simple rule that "every time reader X wants
to use reader
Y, it increfs it" and "whenver reader X is done
using reader Y, it
decrefs it",  all should work correctly.

Also we should think of "close()" as the way that
the external user
does the decref of their reader.  We just special-case this
call, by
setting isOpen=false, to make sure we don't double decref on
a double
close call.

Let's walk through your example...

I'm assuming in your example you meant for reader2 and
reader3 to also
be SegmentReaders?  Ie, the changes that are happening to
the
single-segment index1 are just changes to norms and/or
deletes.  If
not, the example is less interesting because reader1 will be
closed
sooner 

Also in your example let's insert missing
"reader1.close()" as the
very first close?  (Else it will never be closed because
it's RC never
hits 0).

When reader1 is created it has RC 1.

When multiReader1 is created, reader1 now has RC 2.

When multiReader2 is created, reader1 now has RC 3.

When reader2 is created (by reader1.reopen()), it incref's
reader1
because it's sharing the sub-readers in reader1.  So reader1
now has
RC 4.

When reader3 was created (by reader2.reopen()), it incref's
reader2
because it's sharing the sub-readers reader2 contains.  So
reader1 is
still at RC 4 and reader2 is now at RC 2.

Now, we close.

After reader1.close() is called, reader1 sets isOpen=false
(to prevent
double close by the user) and RC drops to 3.

With multiReader1.close(), multiReader1 is not at RC 0, and
so it
decrefs all readers it was using, and so reader1 RC is now
2.

With multiReader2.close(), likewise it is now at RC 0 and so
it
decrefs all readers it was using, and so reader1 RC is now
1.

With reader2.close(), it decrefs its own RC, however that
brings its
RC to 1 (reader3 is still referring to it) and so it does
not decref
the reader1 that it's referring to.

Finally, with reader3.close(), it is now at RC 0 and so it
decrefs the
reader2 it refers to.  This brings reader2's RC to 0, and so
reader2
decrefs the reader1 that it's referring to.  Which brings
reader1's RC
to 0, and so reader1 finally closes all its internal
sub-readers.


> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536413 ] 

Michael Busch commented on LUCENE-743:
--------------------------------------


I'm assuming in your example you meant for reader2 and
reader3 to also
be SegmentReaders?

Yes that's what I meant. Sorry, I didn't make that clear.


Also in your example let's insert missing
"reader1.close()" as the
very first close? (Else it will never be closed because it's
RC never
hits 0).

Doesn't what you describe change the semantics of
MultiReader.close()?

If you do:
{code:java}
IndexReader reader1 = IndexReader.open(index1);  
IndexReader multiReader1 = new MultiReader(new IndexReader[]
{reader1, IndexReader.open(index2)});
multiReader1.close();


then today multiReader1.close() also closes reader1. That's
why I consciously omitted reader1.close().

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();

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.

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

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.

So do you suggest that a MultiReader should increment the
refcounts when it is opened as well (in the constructor)? I
believe we can implement it like this, but as I said it
changes the semantics of MultiReader.close() (and
ParallelReader.close() is, I believe, the same). A user
would then have to close subreaders manually.



> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536353 ] 

michaelbusch edited comment on LUCENE-743 at 10/20/07 3:11
AM:
------------------------------------------------------------
----

Hi Mike,

I'm not sure if I fully understand your comment. Consider
the following (quite constructed) example:

{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
... // modify index1
IndexReader reader2 = reader1.reopen();
// reader2 is a new instance of SegmentReader that shares
resources with reader1
... // modify index1
IndexReader reader3 = reader2.reopen();
// reader3 is a new instance of SegmentReader that shares
resources with reader1 and reader2


Now the user closes the readers in this order:
# multiReader1.close();
# multiReader2.close();
# reader2.close();
# reader3.close();

reader1 should be marked as closed after 2., right? Because
multiReader1.close() and multiReader2.close() have to
decrement reader1's refcount. But the underlying files have
to remain open until after 4., because reader2 and reader3
use reader1's resources.

So don't we need 2 refcount values in reader1? One that
tells us when the reader itself can be marked as closed, and
one that tells when the resources can be closed? Then
multiReader1 and multiReader2 would decrement the first
refCount, whereas reader2 and reader3 both have to
"know" reader1, so that they can decrement the
second refcount.

I hope I'm just completely confused now and someone tells me
that the whole thing is much simpler 



      was (Author: michaelbusch):
    Hi Mike,

I'm not sure if I fully understand your comment. Consider
the following (quite constructed) example:

{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
... // modify index1
IndexReader reader2 = reader1.reopen();
// reader2 is a new instance that shares resources with
reader1
... // modify index1
IndexReader reader3 = reader2.reopen();
// reader3 is a new instance that shares resources with
reader1 and reader2


Now the user closes the readers in this order:
# multiReader1.close();
# multiReader2.close();
# reader2.close();
# reader3.close();

reader1 should be marked as closed after 2., right? Because
multiReader1.close() and multiReader2.close() have to
decrement reader1's refcount. But the underlying files have
to remain open until after 4., because reader2 and reader3
use reader1's resources.

So don't we need 2 refcount values in reader1? One that
tells us when the reader itself can be marked as closed, and
one that tells when the resources can be closed? Then
multiReader1 and multiReader2 would decrement the first
refCount, whereas reader2 and reader3 both have to
"know" reader1, so that they can decrement the
second refcount.

I hope I'm just completely confused now and someone tells me
that the whole thing is much simpler 


  
> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536418 ] 

Michael McCandless commented on LUCENE-743:
-------------------------------------------


If you do:
{code:java}
IndexReader reader1 = IndexReader.open(index1);  
IndexReader multiReader1 = new MultiReader(new IndexReader[]
{reader1, IndexReader.open(index2)});
multiReader1.close();


then today multiReader1.close() also closes reader1. That's
why I consciously omitted reader1.close().


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.


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();

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.


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.


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

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.


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: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536419 ] 

Michael McCandless commented on LUCENE-743:
-------------------------------------------


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.


Actually I retract this: it's no longer necessary as long as
we change
ensureOpen to assert that RC > 0 instead of
closed==false.

I think this is actually a nice unexpected side-effect of
using
reference counting: it resolves this overly aggressive
behavior of
MultiReader/ParallelReader.


> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536805 ] 

Michael Busch commented on LUCENE-743:
--------------------------------------


With that change, plus the change below, your example works
fine.


Two things:
- MultiReader/ParallelReader must not incref the subreaders
on open() 
as you said. But on reopen() it must incref the subreaders
that 
haven't changed and thus are shared with the old
MultiReader/
ParallelReader. This further means, that the re-opened
MultiReader/
ParallelReader must remember which of the subreaders to
decref on
close(), right?

- If we change ensureOpen() like you suggest, then the user
might
still be able to use reader1 (in my example), even after 
reader1.close() was explicitly called. Probably not a big
deal?


> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536827 ] 

Michael McCandless commented on LUCENE-743:
-------------------------------------------


    * MultiReader/ParallelReader must not incref the
subreaders on open()
      as you said. But on reopen() it must incref the
subreaders that
      haven't changed and thus are shared with the old
MultiReader/
      ParallelReader. This further means, that the re-opened
MultiReader/
      ParallelReader must remember which of the subreaders
to decref on
      close(), right?


Hmm, right.  MultiReader/ParallelReader must keep track of
whether it
should call decref() or close() on each of its child
readers, when it
itself is closed.


    * If we change ensureOpen() like you suggest, then the
user might
      still be able to use reader1 (in my example), even
after
      reader1.close() was explicitly called. Probably not a
big deal?


I think this is OK?


> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536845 ] 

Michael Busch commented on LUCENE-743:
--------------------------------------


I think this is OK?


This was essentially the reason why I suggested to use two
refcount values:
one to control when to close a reader, and one to control
when to close
it's (shared) resources in case of SegmentReader. That
approach would not
alter the behaviour of IndexReader.close(). 
But I agree that your approach is simpler and I also think
it is okay to 
change ensureOpen() and accept the slight API change.

So I'll go ahead and implement the refcount approach unless
anybody objects.

Oh and Mike, thanks for bearing with me 

> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536848 ] 

Yonik Seeley commented on LUCENE-743:
-------------------------------------

What about a new constructor for MultiReader/ParallelReader
that implements more sensible semantics (increment refcount
on readers passed to it, and decrement on close())?

> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org

    [ https://issues.apache.org/jira/browse/
LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpan
els:comment-tabpanel#action_12536862 ] 

Michael Busch commented on LUCENE-743:
--------------------------------------


What about a new constructor for MultiReader/ParallelReader
that implements more sensible semantics (increment refcount
on readers passed to it, and decrement on close())?


Yeah, when reference counting is implemented then such a
constructor should be easy to add.

> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: http
s://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: java-dev-unsubscribelucene.apache.org
For additional commands, e-mail: java-dev-helplucene.apache.org