Actually it's perfectly fine for two threads to enter that code
fragment (you obtain a write lock to protect the code so that "there
can be only one").
Second off, even if you didn't have your write lock, the code should
still be safe in that no index corruption is possible. Multiple
threads may
Mike,
I am sorry for wasting your time :). There were indeed two threads that
were performing this operation. Out of curiosity, which part of this is not
thread safe? An indexreader reopening while a commit is going on? Thanks
again for your help.
Regards,
Khawaja
On Thu, Apr 9, 2009 at 5:44
That code looks right. Are there multiple threads that may enter it?
Can you show the code where you create the IndexWriter, add docs, etc?
Can you call IndexWriter.setInfoStream for the entire life of the
index, up until when the optimize error happens, and post back?
Mike
On Thu, Apr 9, 2009
Hi Michael,
Thanks for the quick response. I only have one IndexWriter, and there are
no other processes accessing this particular index. I have tried deleting
the entire index and reconstructing it, but the index corruption is
repeatable. Incidentally, there are no new writes since the last comm
These are serious corruption exceptions.
Is it at all possible two writers are accessing the index at the same time?
Can you describe more about how you're using Lucene?
Mike
On Thu, Apr 9, 2009 at 7:59 PM, Khawaja Shams wrote:
> Hello,
> I am having a problem with reopening the IndexReader w
Hello,
I am having a problem with reopening the IndexReader with Lucene 2.4 ( I
updated to 2.4.1, but still no luck). The exception is preceded by an
exception in optimizing the index. I am not reopening the reader while the
commit or optimization is going on in the writer (optimizing happens in
