Michael McCandless wrote:
Are you sure you can't make the reader reopen block on a reindex? Or
skip reopen if reindex is in process?
(Because that's the simplest solution).
Thats what Im suggesting in principle, I just need to work out the best
way to do it because the reader reopen has no
Are you sure you can't make the reader reopen block on a reindex? Or
skip reopen if reindex is in process?
(Because that's the simplest solution).
If not, I think the next best solution is likely to allow multiple
commit points in the index. You'll need a custom deletion policy that
always keep
Michael McCandless wrote:
Lucene doesn't have anything builtin to handle this.
It's probably best to put synchronization into your code in such a
case? It's presumably also not great if your IndexReader opens an
empty index since searches will find no results. Ie, you should
probably only reop
Michael McCandless wrote:
It's fine if one thread is changing the index (w/ IndexWriter) while
other threads are opening IndexReaders.
Though, if you have IndexWriter opening with "create=true" at the same
time that an IndexReader is attempting to open the index, that would
explain this. Is it
It's fine if one thread is changing the index (w/ IndexWriter) while
other threads are opening IndexReaders.
Though, if you have IndexWriter opening with "create=true" at the same
time that an IndexReader is attempting to open the index, that would
explain this. Is it possible that's happening?
Paul Taylor wrote:
Hi I was using a RAMDirectory and this was working fine but have now
moved over to a filesystem directory to preserve space, the directory
is just initialized once
directory = new RAMDirectory();
directory =
FSDirectory.getDirectory(Platform.getPlatformLicenseFolder()