Following up with the structure of the index dir, and checkIndex output.
*Structure of index:*
06/11/2013 10:55 AM <DIR> .
06/11/2013 10:55 AM <DIR> ..
02/11/2013 01:06 AM 20 segments.gen
01/11/2013 03:00 AM 2,589 segments_29tx
02/11/2013 01:06 AM 2,369 segments_2bsy
01/11/2013 03:00 AM 1,615,209 _1qro.fdt
01/11/2013 03:00 AM 21,612 _1qro.fdx
01/11/2013 03:00 AM 421 _1qro.fnm
01/11/2013 03:00 AM 466,357 _1qro.frq
01/11/2013 03:00 AM 10,808 _1qro.nrm
01/11/2013 03:00 AM 654,674 _1qro.prx
01/11/2013 03:00 AM 11,320 _1qro.tii
01/11/2013 03:00 AM 866,215 _1qro.tis
01/11/2013 03:00 AM 346 _1qro_p0.del
01/11/2013 03:00 AM 2,215,825 _24xf.cfs
01/11/2013 03:00 AM 214 _24xf_9k.del
01/11/2013 03:00 AM 993,243 _2czq.cfs
01/11/2013 03:00 AM 94 _2czq_3.del
01/11/2013 03:00 AM 2,688,823 _2d00.cfs
01/11/2013 03:00 AM 15 _2d00_1.del
01/11/2013 03:00 AM 1,310,966 _2iwt.cfs
01/11/2013 03:00 AM 112 _2iwt_1.del
01/11/2013 03:00 AM 79,481 _2iwz.cfs
01/11/2013 03:00 AM 2,501,932 _6k.cfs
01/11/2013 03:00 AM 259 _6k_62.del
01/11/2013 03:00 AM 2,596,920 _6l.cfs
01/11/2013 03:00 AM 259 _6l_hx.del
01/11/2013 03:00 AM 2,049,757 _9n.fdt
01/11/2013 03:00 AM 33,132 _9n.fdx
01/11/2013 03:00 AM 382 _9n.fnm
01/11/2013 03:00 AM 467,759 _9n.frq
01/11/2013 03:00 AM 16,568 _9n.nrm
01/11/2013 03:00 AM 620,251 _9n.prx
01/11/2013 03:00 AM 11,680 _9n.tii
01/11/2013 03:00 AM 878,430 _9n.tis
01/11/2013 03:00 AM 526 _9n_2t.del
01/11/2013 03:00 AM 11,064,537 _9o.fdt
01/11/2013 03:00 AM 159,996 _9o.fdx
01/11/2013 03:00 AM 382 _9o.fnm
01/11/2013 03:00 AM 2,988,122 _9o.frq
01/11/2013 03:00 AM 80,000 _9o.nrm
01/11/2013 03:00 AM 4,118,225 _9o.prx
01/11/2013 03:00 AM 50,218 _9o.tii
01/11/2013 03:00 AM 4,066,962 _9o.tis
01/11/2013 03:00 AM 2,508 _9o_lg.del
01/11/2013 03:00 AM 1,731,476 _ug3.fdt
01/11/2013 03:00 AM 23,596 _ug3.fdx
01/11/2013 03:00 AM 421 _ug3.fnm
01/11/2013 03:00 AM 496,290 _ug3.frq
01/11/2013 03:00 AM 11,800 _ug3.nrm
01/11/2013 03:00 AM 687,953 _ug3.prx
01/11/2013 03:00 AM 12,280 _ug3.tii
01/11/2013 03:00 AM 920,751 _ug3.tis
01/11/2013 03:00 AM 377 _ug3_10g.del
52 File(s) 46,534,462 bytes
*CheckIndex output:*
status.clean=false
status.numBadSegments=3
status.numSegments=10
status.segmentFormat=FORMAT_3_1 [Lucene 3.1]
status.segmentsFileName=segments_2bsy
status.totLoseDocCount=5459
status.cantOpenSegments=false
status.missingSegments=false
status.missingSegmentVersion=false
status.partial=false
status.segmentInfos=[org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@ccdc6162,
org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@3cd10a77,
org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@c5d1f95b,
org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@e29a4dbc,
org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@fe7664a1,
org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@e18ca53e,
org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@b2901de3,
org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@3e558803,
org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@c34ccd0b,
org.apache.lucene.index.CheckIndex$Status$SegmentInfoStatus@f4719e19]
status.segmentsChecked=[]
status.toolOutOfDate=false
status.userData={VERSION=9460}
On Wed, Nov 6, 2013 at 12:38 AM, Gili Nachum <[email protected]> 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)
>
