To answer my own question here, I switched from the default NativeFSLockFactory to the SimpleFSLockFactory. This allows me to detect when the IndexWriter was not properly closed since an attempt to open a new one will throw a LockObtainFailedException, which I can key on to know to rebuild the index. The NativeFSLockFactory confused me a bit since although it writes a write.lock file, an NIO FileLock on that file actually serves as the lock rather than the file itself. So it didn't detect the condition where the old write.lock file had been left behind.
-Tommy -----Original Message----- From: Becker, Thomas [mailto:thomas.bec...@netapp.com] Sent: Friday, April 05, 2013 1:33 PM To: java-user@lucene.apache.org Subject: Detecting when an index was not closed properly We are doing some crash resiliency testing of our application. One of the things we found is that the Lucene index seems to get out of sync with the database pretty easily. I suspect this is because we are using near real time readers and never actually calling IndexWriter.commit(). I'm trying to decide on the best way to handle this problem. One is obviously we could move to calling commit() when we update the index. Alternatively, we could rebuild the index fairly easily if we knew that it was closed improperly. Is there an easy way to detect this? Or am I wrong to avoid calling commit()? Thanks, Tommy --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
