No, it's not supposed to happen :) That exception is happening because IW is trying to apply the deletes during flush, and needs to open a reader for all existing segments to do so, and then finds that 33gg.cfs does not exist.
Which is odd, because from your ls -l output, you have no segments even close to _33gg; the newest segment I see in your listing is _21wz. So it's very weird that IW thought such a segment would exist. Do you ever call addIndexes(Directory[])? Is this a remote filesystem? Mounted via NFS? Can you post the command-line output from CheckIndex, not the programmatic output? Maybe it includes more details. The index is not exposed to corruptions during commit nor addIndexes; if bad things (computer loses power, JVM or OS crashes) happen during these methods then on reboot/restart the index will show whatever its state was as of the last successful commit. Mike McCandless http://blog.mikemccandless.com On Tue, Nov 5, 2013 at 5:38 PM, Gili Nachum <gilinac...@gmail.com> wrote: > Hello, > I got an index corruption in production, and was wondering if it might be a > known bug (still with Lucene 3.1), or is my code doing something wrong. > It's a local disk index. No known machine power lose. No suppose to even > happen, right? > > This index that got corrupted is updated every 30sec; adding to it a small > delta's index (using addIndexes()) that was replicated from another machine. > The series of writer actions to update the index is: > 1. writer.deleteDocuments(q); > 2. writer.flush(false, true); > 3. writer.addIndexes(reader); > 4. writer.commit(map); > > Is the index exposed to corruptions only during commit, or is addIndexes() > risky by itself (doc says it's not). > LUCENE-2610 <https://issues.apache.org/jira/browse/LUCENE-2610> kind of > looks in the neberhood, though it's not a bug report. > I'll add an ls -l output in a follow up email. > > Technically the first indication of problems is when calling flush, but it > could be that the previous writer action left it broken for flush to fail. > My stack trace is: > Caused by: java.io.FileNotFoundException: > /disks/data1/opt/WAS/LotusConnections/Data/catalog/index/Places/index/_33gg.cfs > (No such file or directory) > at java.io.RandomAccessFile.open(Native Method) > at java.io.RandomAccessFile.<init>(RandomAccessFile.java:233) > at > org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput$Descriptor.<init>(SimpleFSDirectory.java:69) > at > org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput.<init>(SimpleFSDirectory.java:90) > at > org.apache.lucene.store.NIOFSDirectory$NIOFSIndexInput.<init>(NIOFSDirectory.java:91) > at > org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:78) > at > org.apache.lucene.index.CompoundFileReader.<init>(CompoundFileReader.java:66) > at > org.apache.lucene.index.SegmentReader$CoreReaders.<init>(SegmentReader.java:113) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:578) > at > org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:684) > at > org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:659) > at > org.apache.lucene.index.BufferedDeletes.applyDeletes(BufferedDeletes.java:283) > at > org.apache.lucene.index.BufferedDeletes.applyDeletes(BufferedDeletes.java:191) > at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3358) > at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3296) --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
