lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-2858) Separate SegmentReaders (and other atomic readers) from composite IndexReaders
Date Fri, 01 Jun 2012 17:50:23 GMT


Michael McCandless commented on LUCENE-2858:

Not entirely sure why but it looks like the commits here slowed down our NRT reopen latency.
 If you look at the nightly bench graph:
and click + drag from Jan 2012 to today, annotation R shows we increased from ~46 msec NRT
reopen latency to ~50 msec ... could just be hotspot being upset...
> Separate SegmentReaders (and other atomic readers) from composite IndexReaders
> ------------------------------------------------------------------------------
>                 Key: LUCENE-2858
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>            Priority: Blocker
>             Fix For: 4.0
>         Attachments: LUCENE-2858-FCinsanity.patch, LUCENE-2858-FixSlowEnsureOpen.patch,
LUCENE-2858.patch, LUCENE-2858.patch
> With current trunk, whenever you open an IndexReader on a directory you get back a DirectoryReader
which is a composite reader. The interface of IndexReader has now lots of methods that simply
throw UOE (in fact more than 50% of all methods that are commonly used ones are unuseable
now). This confuses users and makes the API hard to understand.
> This issue should split "atomic readers" from "reader collections" with a separate API.
After that, you are no longer able, to get TermsEnum without wrapping from those composite
readers. We currently have helper classes for wrapping (SlowMultiReaderWrapper - please rename,
the name is really ugly; or Multi*), those should be retrofitted to implement the correct
classes (SlowMultiReaderWrapper would be an atomic reader but takes a composite reader as
ctor param, maybe it could also simply take a List<AtomicReader>). In my opinion, maybe
composite readers could implement some collection APIs and also have the ReaderUtil method
directly built in (possibly as a "view" in the util.Collection sense). In general composite
readers do not really need to look like the previous IndexReaders, they could simply be a
"collection" of SegmentReaders with some functionality like reopen.
> On the other side, atomic readers do not need reopen logic anymore? When a segment changes,
you need a new atomic reader? - maybe because of deletions thats not the best idea, but we
should investigate. Maybe make the whole reopen logic simplier to use (ast least on the collection
reader level).
> We should decide about good names, i have no preference at the moment.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message