Thanks for the response Michael. Sorry, I'm using Lucene 2.2. We are using Lucene to index our database (Oracle) into documents for full-text search feature. Here is the process of indexing,
1) Have two IndexWriters which run in two different threads and write to two different directories (temporary indexes). They both read from the same queue (db resultset queue) and then right to the index. Close the indexwriters once done. 2) Once the IndexWriters are done we start the MasterIndex, which is another IndexWriter. This merges the indexes in those two temporary indexes. 3) Once the writer.addIndexes is done I call writer.optimize() and then writer.close(). 4) Our IndexSearcher reads only from the MasterIndex Once in a while we kill the running application using "kill -9". I think if the IndexWriter is in process of merging and we kill it we run into this problem. It has already happened few times in last one week. I do clean up the lock if there is a write.lock at the startup of the system. I can not recreate the index as it may take hours to re-index. I don't have any shutdown hook right now, but I'm thinking of adding one for graceful index closing. We use following merge parameters, mergeFactor=100 maxMergeDocs=99999 maxBufferedDocs=1000 I can try out your tool, is it something that can be integrated into the application itself? So, basically I'm looking to catch the "FileNotFoundException" and take some action to recover from it. Thanks, -vivek On 10/5/07, Michael McCandless <[EMAIL PROTECTED]> wrote: > "vivek sar" <[EMAIL PROTECTED]> wrote: > > > We are using Lucene 2.3. > > Do you mean Lucene 2.2? Your stack trace seems to line up with 2.2, > and 2.3 isn't quite released yet. > > > The problem we are facing is quite a few times if our application is > > stopped (killed or crash) while Indexer is doing its job, the next > > time when we bring up the application the Indexer fails to run with > > the following exception, > > > 2007-10-04 12:29:53,089 ERROR [PS thread 10] IndexerJob - Full-text > > indexer failed to index > > java.io.FileNotFoundException: > > /opt/manager/apps/conf/index/MasterIndex/_llb.cfs (No such file or > > directory) > > at java.io.RandomAccessFile.open(Native Method) > > at java.io.RandomAccessFile.<init>(Unknown Source) > > at > > > > org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor.<init>(FSDirectory.java:506) > > at > > > > org.apache.lucene.store.FSDirectory$FSIndexInput.<init>(FSDirectory.java:536) > > at > > org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:445) > > at > > > > org.apache.lucene.index.CompoundFileReader.<init>(CompoundFileReader.java:70) > > at > > > > org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:181) > > at > > org.apache.lucene.index.SegmentReader.get(SegmentReader.java:167) > > at > > org.apache.lucene.index.SegmentReader.get(SegmentReader.java:131) > > at > > org.apache.lucene.index.IndexReader$1.doBody(IndexReader.java:206) > > at > > > > org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:610) > > > > The search also doesn't work after this. > > Can you share some details of how you are using Lucene, and, how/why > it's killed or crashed so often? When it crashes, do you get an > exception from Lucene (which could be the root cause here)? > > What OS and filesystem is the index on? Are you changing any default > settings like autoCommit, lock factory & lock file location, etc? > > Even if Lucene (JVM) is killed, the index should not become corrupt in > this particular way, unless the IO system fails to complete its > "write" operations. Lucene always writes & closes new segments files > (_llb.cfs) before writing the segments_N file that refers to them. > > > Looks like the index were left in some weird state (might be > > corrupted). I was wondering if there is a tool or a way to repair the > > indexes if we are not able to open them at run-time? > > I just took a first stab at just such a tool, here: > > https://issues.apache.org/jira/browse/LUCENE-1020 > > Please be very very careful!: I just wrote this code and it could have > some horrible bug that destroys your index. So make a backup of your > index first. > > Could you first run that tool without the "-fix" option and post back > the resulting output? > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
