On Fri, Nov 8, 2013 at 12:22 AM, Ravikumar Govindarajan <ravikumar.govindara...@gmail.com> 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 http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
