lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: IndexReader close listeners and NRT
Date Fri, 08 Nov 2013 12:47:59 GMT
On Fri, Nov 8, 2013 at 12:22 AM, Ravikumar Govindarajan
<> wrote:
>> So, in your code, "reader" is the top-level reader, not the one
>> segment you are pulling a scorer on (context.reader()).
>> So you are building your cache on the top-level reader, not the
>> segment's reader?  Is that intentional?  (It's not NRT friendly).
> Not really. It is an IndexSearcher(AtomicReader) that populates the BitSet

Hmm, I see the code referencing "reader" but it never assigns it?  So
I assumed this was your toplevel reader (somewhere).  Maybe you are
missing an AtomicReader reader = context.getReader() in that code?

>> But, yes, your ReaderClosedListener will be called once that top-level
>> reader is closed, and that will then evict its entries from the cache.
> This is the current problem I am facing. I actually want to key on
> CoreClosedListener for this cache, but lucene exposes only a
> ReaderClosedListener(), which causes frequent purge/build of the cache
> during NRT life-cycle.
> Is it possible to hook into a CoreClosedListener somehow, so that I can
> mimic FieldCacheImpl behavior and become free from NRT logic?

You can cast the AtomicReader to SegmentReader and call .addCoreClosedListener?

> Also, when we have a getCoreCacheKey() exposed from IndexReader, should we
> also not have a addCoreClosedListener() in it? Will it cause too much
> confusion, as only SegmentReader might have a valid impl for that method?

You really should only use .getCoreCacheKey on SegmentReader; all
other impls will just "return this" (and then you have full cache
turnover after every NRT reopen).

Mike McCandless

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

View raw message