Thanks Mike. Explicit type-cast to SegmentReader will do the trick for the moment.
-- Ravi On Fri, Nov 8, 2013 at 6:17 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > 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 > >
