That's a good idea, if your index is "large enough", and/or you make
heavy use of FieldCache (eg, sorting by field), regardless of whether
you use NRT or "normal" commit + reopen to reopen your reader.
Mike McCandless
http://blog.mikemccandless.com
On Sun, Oct 30, 2011 at 7:36 PM, Denis Bazhenov
Well, if so I guess I should use IndexWarmer to warm up IndexReader before
publishing reference to search clients. At least it will pre read all the
segments in RAM before issuing search.
On Oct 17, 2011, at 9:47 PM, Michael McCandless wrote:
> You'll have to call .commit() from the IndexWriter
You'll have to call .commit() from the IndexWriter to make the changes
externally visible.
The call IndexReader.reopen to get a reader seeing the committed
changes; the reopen will be efficient (only open "new" segments vs the
old reader).
It's still best to use near-real-time reader when possibl
In my experience, reopen will find all changes on an index, whether it was
modified by the same process or not. If you're replicating over a network,
you might need some barrier / lock around the reopen call to make sure the
replicated index is complete. Obviously with something as fickle as a
netw
We have situation when lucene index is replicated over network. And on that
machine reader reopen doesn't make new documents visible to a search.
As far as I know IndexReader.reopen() call does work only if changes are
applied using the linked IndexWriter. My question is: how can I implement
ef
