"Bill Janssen" <[EMAIL PROTECTED]> wrote: > Here's the dump with last night's build:
Those logs look healthy up until the exception. One odd thing is when you instantiate your writer, your index has 2 segments in it. I expected only 1 since each time you visit your index you leave it optimized. (Or, maybe you're not calling setInfoStream immediately after opening the writer?). The error still only happens on the one PPC machine, even after upgrading to trunk? EG not on an Intel box? Have you tried another PPC machine? > I'm going back to the old code now. It uses the 2.0 APIs, so it > uses an IndexReader to delete the existing instances, then closes > that reader (which if I understand it properly should flush the > index back to disk), then creates a new writer to re-index the same > documents, then does the optimize with that writer, which is where > the CorruptIndexException started coming up. I'm going to run that > again with 2.0, then with last night's build. Could you post this part of the code (deleting) too? > I'm not sure if the success with 2.0 meant that a corrupted index > wasn't being detected, or if it wasn't being corrupted in the first > place. Likely the corruption really isn't happening. That particular check for "docs out of order" is present in 2.0 as well. Is it possible to whittle down your test to a smaller set of documents? EG if you only re-index one document at a time, does the exception happen sooner? Ideally we can reduce this to a test I can reproduce then I can track it down... Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
