lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Busch (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-743) IndexReader.reopen()
Date Sat, 10 Nov 2007 06:47:50 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Busch updated LUCENE-743:
---------------------------------

    Attachment: lucene-743-take6.patch

Changes in this patch:

- Fixed ParallelReader and MultiReader so that they don't incRef the subreaders anymore in
case reopen() is a NOOP (i. e. reopen() doesn't return a new instance)
- In the new ctr in MultiSegmentReader it was possible to hit a NullPointerException during
filling the norms cache, because I didn't check for null after retrieving the old reader from
the HashMap. I fixed this.
- SegmentReader now also overwrites decRef() and implements decRefReaderNotNorms(). 
- As Mike suggested I removed "boolean sharedNorms" from SegmentReader. Now in MultiSegmentReader
I compare the norm instances from the old and the new subReaders and copy the bytes to the
new cache in case they are ==.
- In SegmentReader I changed norms to be a HashMap instead of HashTable.
- Norm.decRef() and Norm.incRef() are synchronized now.
- SegmentReader#norms(String field, byte[] bytes, int offset) now synchronizes on the norm
object that is to be read.
- SegmentReader#reopen() now opens a new FieldsReader because it is not thread-safe.
- SegmentReader.Norm has a new boolean variable "useSingleNormStream". SegmentReader#norms(String
field, byte[] bytes, int offset) checks if it is true. If yes, then the readers' singleNormStream
is used, otherwise norm.in. This is necessary so that a reopened SegmentReader always uses
its own singleNormStream and to avoid synchronization on the singleNormStream.
- I added a bunch of code to TestIndexReaderReopen to test the thread-safety of reopen().
It starts 150 threads: some modify the index (some delete docs, some add docs and some set
norms), some reopen readers and check if the re-opened ones deliver the same results as fresh
ones.
- assertReaderClosed now checks if the norms are closed and also checks recursively if all
subReaders are closed.

Still outstanding:
- On the IBM JVM all tests pass. On Sun, the thread-safety test *sometimes* fails. When it
fails, then in assertReaderClosed, because the refCounts of either the norms or some subReaders
aren't 0 at the end of the test. At this point I'm not sure why and I'm still debugging. I
just wanted to submit the patch to give others the chance to review the patch or possibly
(hopefully) find the problem before me.

> 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-take3.patch,
lucene-743-take4.patch, lucene-743-take5.patch, lucene-743-take6.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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message