lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Becker, Thomas" <>
Subject RE: Detecting when an index was not closed properly
Date Tue, 09 Apr 2013 17:07:21 GMT
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.


-----Original Message-----
From: Becker, Thomas [] 
Sent: Friday, April 05, 2013 1:33 PM
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()?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message