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 idea whether a reindex is
occurring athe moment, I have to introduce some concurrency code to
achive this.
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 keeps the "last commit point that's safe to reopen" in the
index. Then a reindex can gleefully proceed since the last "safe to
reopen" commit point will not be deleted. If a reader wants to
reopen, you ask it to reopen on that "last safe commit point".
But these APIs (reopen to a commit point) are only available in 2.9
trunk. You can emulate this in prior releases by using separate
indexing directories in the filesystem.
I had already upgraded to 2.9, so I'll have a look at this as well. For
me I would want it to work so that before a reindex starts it creates a
commit point on the existing index, so a that any index readers created
in the meantime will work on the last one
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
