lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chuck Williams (JIRA)" <>
Subject [jira] Created: (LUCENE-1037) Corrupt index: term out of order after forced stop during indexing
Date Sun, 28 Oct 2007 22:15:50 GMT
Corrupt index:  term out of order after forced stop during indexing

                 Key: LUCENE-1037
             Project: Lucene - Java
          Issue Type: Bug
          Components: Index
    Affects Versions: 2.0.1
         Environment: Windows Server 2003
            Reporter: Chuck Williams

In testing a reboot during active indexing, upon restart this exception occurred:

Caused by: term out of order ("ancestorForwarders:".compareTo("descendantMoneyAmounts:$0.351")
<= 0)

	at org.apache.lucene.index.TermInfosWriter.add(

	at org.apache.lucene.index.SegmentMerger.mergeTermInfo(

	at org.apache.lucene.index.SegmentMerger.mergeTermInfos(

	at org.apache.lucene.index.SegmentMerger.mergeTerms(

	at org.apache.lucene.index.SegmentMerger.merge(

	at org.apache.lucene.index.IndexWriter.mergeSegments(

	at org.apache.lucene.index.IndexWriter.optimize(

	at ...   (application code)

The "ancestorForwarders:" term has no text.  The application never creates such a term.  It
seems  the reboot occurred while this term was being written, but such a segment should not
be linked into the index and so should not be visible after restart.

The application uses parallel subindexes accessed with ParallelReader.  This reboot caught
the system in a state where the indexes were out of sync, i.e. a new document had parts indexed
in one subindex but not yet indexed in another.  The application detects this condition upon
restart, uses IndexReader.deleteDocument() to delete the parts that were indexed from those
subindexes, and then does optimize() all all the subindexes to bring the docid's back into
sync.  The optimize() failed, presumably on a subindex that was being written at the time
of the reboot.  This subindex would not have completed its document part and so no deleteDocument()
would have been performed on it prior to the optimize().

The version of Lucene here is from January 2007.  I see one other reference to this exception
in LUCENE-848.  There is a note there that the exception is likely a core problem, but I don't
see any follow up to track it down.

Any ideas how this could happen?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

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

View raw message