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
