[jira] Created: (LUCENE-555) Index Corruption

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (LUCENE-555) Index Corruption

Sebastian Nagel (Jira)
     [ http://issues.apache.org/jira/browse/LUCENE-555?page=all ]
     
Otis Gospodnetic resolved LUCENE-555:
-------------------------------------

    Resolution: Incomplete

A small index for reproduction of the bug was never provided and it doesn't look like the original reporter still has problems with this.

> Index Corruption
> ----------------
>
>          Key: LUCENE-555
>          URL: http://issues.apache.org/jira/browse/LUCENE-555
>      Project: Lucene - Java
>         Type: Bug

>   Components: Index
>     Versions: 1.9
>  Environment: Linux FC4, Java 1.4.9
>     Reporter: dan
>     Priority: Critical

>
> Index Corruption
> >>>>>>>>> output
> java.io.FileNotFoundException: ../_aki.fnm (No such file or directory)
>         at java.io.RandomAccessFile.open(Native Method)
>         at java.io.RandomAccessFile.<init>(RandomAccessFile.java:204)
>         at org.apache.lucene.store.FSIndexInput$Descriptor.<init>(FSDirectory.java:425)
>         at org.apache.lucene.store.FSIndexInput.<init>(FSDirectory.java:434)
>         at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324)
>         at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:56)
>         at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658)
>         at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517)
> >>>>>>>>> input
> - I open an index, I read, I write, I optimize, and eventually the above happens. The index is unusable.
> - This has happened to me somewhere between 20 and 30 times now - on indexes of different shapes and sizes.
> - I don't know the reason. But, the following requirement applies regardless.
> >>>>>>>>> requirement
> - Like all modern database programs, there has to be a way to repair an index. Period.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-555) Index Corruption

Sebastian Nagel (Jira)
In reply to this post by Sebastian Nagel (Jira)
    [ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12444827 ]
           
Tero Hagström commented on LUCENE-555:
--------------------------------------

We've experienced Lucene index corruption a few times on a production system. What makes it tricky is, that 1) the ability to search the Lucene index is critical in that system, and 2) recreating it takes rather long. Thus the index corruption renders the system unusable for a long period.

The latest index corruption appears to have resulted from a disk partition being full. I would expect that Lucene would fail gracefully in that situation and not corrupt it's index.

Any chance of reopening this issue?




> Index Corruption
> ----------------
>
>                 Key: LUCENE-555
>                 URL: http://issues.apache.org/jira/browse/LUCENE-555
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 1.9
>         Environment: Linux FC4, Java 1.4.9
>            Reporter: dan
>            Priority: Critical
>
> Index Corruption
> >>>>>>>>> output
> java.io.FileNotFoundException: ../_aki.fnm (No such file or directory)
>         at java.io.RandomAccessFile.open(Native Method)
>         at java.io.RandomAccessFile.<init>(RandomAccessFile.java:204)
>         at org.apache.lucene.store.FSIndexInput$Descriptor.<init>(FSDirectory.java:425)
>         at org.apache.lucene.store.FSIndexInput.<init>(FSDirectory.java:434)
>         at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324)
>         at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:56)
>         at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658)
>         at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517)
> >>>>>>>>> input
> - I open an index, I read, I write, I optimize, and eventually the above happens. The index is unusable.
> - This has happened to me somewhere between 20 and 30 times now - on indexes of different shapes and sizes.
> - I don't know the reason. But, the following requirement applies regardless.
> >>>>>>>>> requirement
> - Like all modern database programs, there has to be a way to repair an index. Period.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-555) Index Corruption

Sebastian Nagel (Jira)
In reply to this post by Sebastian Nagel (Jira)
    [ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12444919 ]
           
Otis Gospodnetic commented on LUCENE-555:
-----------------------------------------

Tero - I suggest you open a new issue, if you want.  Unlike the original issue here, you know why your index got corrupted - full disk.
That said, I doubt we'll have disk-space-checking in Lucene any time soon, since different operating systems have different ways of reporting available disk space.  Hadoop may have some tricks for that, though.

My suggestion to you would be to monitor your disks.  That's the basic stuff you need for any non-toy production system.  If available disk space < N%, send alerts and figure out what to do.


> Index Corruption
> ----------------
>
>                 Key: LUCENE-555
>                 URL: http://issues.apache.org/jira/browse/LUCENE-555
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 1.9
>         Environment: Linux FC4, Java 1.4.9
>            Reporter: dan
>            Priority: Critical
>
> Index Corruption
> >>>>>>>>> output
> java.io.FileNotFoundException: ../_aki.fnm (No such file or directory)
>         at java.io.RandomAccessFile.open(Native Method)
>         at java.io.RandomAccessFile.<init>(RandomAccessFile.java:204)
>         at org.apache.lucene.store.FSIndexInput$Descriptor.<init>(FSDirectory.java:425)
>         at org.apache.lucene.store.FSIndexInput.<init>(FSDirectory.java:434)
>         at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324)
>         at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:56)
>         at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658)
>         at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517)
> >>>>>>>>> input
> - I open an index, I read, I write, I optimize, and eventually the above happens. The index is unusable.
> - This has happened to me somewhere between 20 and 30 times now - on indexes of different shapes and sizes.
> - I don't know the reason. But, the following requirement applies regardless.
> >>>>>>>>> requirement
> - Like all modern database programs, there has to be a way to repair an index. Period.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-555) Index Corruption

Sebastian Nagel (Jira)
In reply to this post by Sebastian Nagel (Jira)
    [ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12444925 ]
           
Michael McCandless commented on LUCENE-555:
-------------------------------------------

I would also add: I'm very surprised disk full corrupts the Lucene index.  I can't explain it.  I'd like to explain it and fix it so if we can get to the root cause here that'd be wonderful.

The worst that should happen on disk full is those recent documents you had added but writer has not yet committed, would be lost (but the rest of the index is intact).

It's only upon successfully writing the new segments that Lucene will write a new "segments" file referring to the new segments.  After that, it removes the old segments.  Since it makes these changes in the correct order, it should be the case that disk full exception never affects the already written index.

Is it possible that disk full fails to throw an exception?  That would be spooky.

Note that I haven' t tested this myself; this is just based on my current understanding of the Lucene source code.  Does anyone see a case now where disk full could corrupt the index?

> Index Corruption
> ----------------
>
>                 Key: LUCENE-555
>                 URL: http://issues.apache.org/jira/browse/LUCENE-555
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 1.9
>         Environment: Linux FC4, Java 1.4.9
>            Reporter: dan
>            Priority: Critical
>
> Index Corruption
> >>>>>>>>> output
> java.io.FileNotFoundException: ../_aki.fnm (No such file or directory)
>         at java.io.RandomAccessFile.open(Native Method)
>         at java.io.RandomAccessFile.<init>(RandomAccessFile.java:204)
>         at org.apache.lucene.store.FSIndexInput$Descriptor.<init>(FSDirectory.java:425)
>         at org.apache.lucene.store.FSIndexInput.<init>(FSDirectory.java:434)
>         at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324)
>         at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:56)
>         at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658)
>         at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517)
> >>>>>>>>> input
> - I open an index, I read, I write, I optimize, and eventually the above happens. The index is unusable.
> - This has happened to me somewhere between 20 and 30 times now - on indexes of different shapes and sizes.
> - I don't know the reason. But, the following requirement applies regardless.
> >>>>>>>>> requirement
> - Like all modern database programs, there has to be a way to repair an index. Period.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-555) Index Corruption

Sebastian Nagel (Jira)
In reply to this post by Sebastian Nagel (Jira)
    [ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12444998 ]
           
Michael McCandless commented on LUCENE-555:
-------------------------------------------

Tero, one question: are you copying or rsync'ing the index from where the writers write it, to where the readers read it?  Or, are your readers reading the same index that the writer wrote to?

> Index Corruption
> ----------------
>
>                 Key: LUCENE-555
>                 URL: http://issues.apache.org/jira/browse/LUCENE-555
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 1.9
>         Environment: Linux FC4, Java 1.4.9
>            Reporter: dan
>            Priority: Critical
>
> Index Corruption
> >>>>>>>>> output
> java.io.FileNotFoundException: ../_aki.fnm (No such file or directory)
>         at java.io.RandomAccessFile.open(Native Method)
>         at java.io.RandomAccessFile.<init>(RandomAccessFile.java:204)
>         at org.apache.lucene.store.FSIndexInput$Descriptor.<init>(FSDirectory.java:425)
>         at org.apache.lucene.store.FSIndexInput.<init>(FSDirectory.java:434)
>         at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324)
>         at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:56)
>         at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658)
>         at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517)
> >>>>>>>>> input
> - I open an index, I read, I write, I optimize, and eventually the above happens. The index is unusable.
> - This has happened to me somewhere between 20 and 30 times now - on indexes of different shapes and sizes.
> - I don't know the reason. But, the following requirement applies regardless.
> >>>>>>>>> requirement
> - Like all modern database programs, there has to be a way to repair an index. Period.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (LUCENE-555) Index Corruption

Ning Li-3
In reply to this post by Sebastian Nagel (Jira)
> It's only upon successfully writing the new segments that Lucene will write a new "segments" file referring to the new segments.  After that, it removes the old segments.  Since it makes these changes in the correct order, it should be the case that disk full exception never affects the already written index.

Lucene could produce an inconsistent index if addIndexes(Directory[])
does not run to its completion. The following is my recent comment on
another issue.

"This makes me notice a bug in current addIndexes(Directory[]). In
current addIndexes(Directory[]), segment infos in S are added to T's
"segmentInfos" upfront. Then segments in S are merged to T several at
a time. Every merge is committed with T's "segmentInfos". So if a
reader is opened on T while addIndexes(Directory[]) is going on, it
could see an inconsistent index."

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (LUCENE-555) Index Corruption

Michael McCandless-2
Ning Li wrote:

>> It's only upon successfully writing the new segments that Lucene will
>> write a new "segments" file referring to the new segments.  After
>> that, it removes the old segments.  Since it makes these changes in
>> the correct order, it should be the case that disk full exception
>> never affects the already written index.
>
> Lucene could produce an inconsistent index if addIndexes(Directory[])
> does not run to its completion. The following is my recent comment on
> another issue.
>
> "This makes me notice a bug in current addIndexes(Directory[]). In
> current addIndexes(Directory[]), segment infos in S are added to T's
> "segmentInfos" upfront. Then segments in S are merged to T several at
> a time. Every merge is committed with T's "segmentInfos". So if a
> reader is opened on T while addIndexes(Directory[]) is going on, it
> could see an inconsistent index."

Oh, ugh.  I will open an issue for this.  I think we should try to fix this.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-555) Index Corruption

Sebastian Nagel (Jira)
In reply to this post by Sebastian Nagel (Jira)
    [ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12445305 ]
           
Michael McCandless commented on LUCENE-555:
-------------------------------------------

Just copying this off the dev list -- there is indeed at least one place where if a writer crashes it can leave the index unloadable.  I will open a new issue on this.

Tero, by any chance are you using addIndexes?

Ning Li says:

Lucene could produce an inconsistent index if addIndexes(Directory[])
does not run to its completion. The following is my recent comment on
another issue.

"This makes me notice a bug in current addIndexes(Directory[]). In
current addIndexes(Directory[]), segment infos in S are added to T's
"segmentInfos" upfront. Then segments in S are merged to T several at
a time. Every merge is committed with T's "segmentInfos". So if a
reader is opened on T while addIndexes(Directory[]) is going on, it
could see an inconsistent index."


> Index Corruption
> ----------------
>
>                 Key: LUCENE-555
>                 URL: http://issues.apache.org/jira/browse/LUCENE-555
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 1.9
>         Environment: Linux FC4, Java 1.4.9
>            Reporter: dan
>            Priority: Critical
>
> Index Corruption
> >>>>>>>>> output
> java.io.FileNotFoundException: ../_aki.fnm (No such file or directory)
>         at java.io.RandomAccessFile.open(Native Method)
>         at java.io.RandomAccessFile.<init>(RandomAccessFile.java:204)
>         at org.apache.lucene.store.FSIndexInput$Descriptor.<init>(FSDirectory.java:425)
>         at org.apache.lucene.store.FSIndexInput.<init>(FSDirectory.java:434)
>         at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324)
>         at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:56)
>         at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658)
>         at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517)
> >>>>>>>>> input
> - I open an index, I read, I write, I optimize, and eventually the above happens. The index is unusable.
> - This has happened to me somewhere between 20 and 30 times now - on indexes of different shapes and sizes.
> - I don't know the reason. But, the following requirement applies regardless.
> >>>>>>>>> requirement
> - Like all modern database programs, there has to be a way to repair an index. Period.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-555) Index Corruption

Sebastian Nagel (Jira)
In reply to this post by Sebastian Nagel (Jira)
    [ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12445520 ]
           
Tero Hagström commented on LUCENE-555:
--------------------------------------

We managed to identify the source of the index corruption. A system administrator manually removed a file from the index to free disk space after receiving an alert on low free disk space.

So, "appears to have resulted from a disk partition being full", while being true in a sort of indirect manner, is by no means basis for reopening this or another issue. Sorry for causing undue alarm. Mea culpa.

We still have one unidentified Lucene index corruption to account for. That one happened roughly at the same time that HW failure testing was done on the SAN used for storing the Lucene index. Basically disconnecting optical fibers on the fly.

That happened a while ago and I don't have enough details to file a decent bug report.

I think we'll settle for the fact that the Lucene index can get corrupt for one reason or another (some of which are not in the realm of Lucene developers), and concentrate on having a good backup policy.







> Index Corruption
> ----------------
>
>                 Key: LUCENE-555
>                 URL: http://issues.apache.org/jira/browse/LUCENE-555
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 1.9
>         Environment: Linux FC4, Java 1.4.9
>            Reporter: dan
>            Priority: Critical
>
> Index Corruption
> >>>>>>>>> output
> java.io.FileNotFoundException: ../_aki.fnm (No such file or directory)
>         at java.io.RandomAccessFile.open(Native Method)
>         at java.io.RandomAccessFile.<init>(RandomAccessFile.java:204)
>         at org.apache.lucene.store.FSIndexInput$Descriptor.<init>(FSDirectory.java:425)
>         at org.apache.lucene.store.FSIndexInput.<init>(FSDirectory.java:434)
>         at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324)
>         at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:56)
>         at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658)
>         at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517)
> >>>>>>>>> input
> - I open an index, I read, I write, I optimize, and eventually the above happens. The index is unusable.
> - This has happened to me somewhere between 20 and 30 times now - on indexes of different shapes and sizes.
> - I don't know the reason. But, the following requirement applies regardless.
> >>>>>>>>> requirement
> - Like all modern database programs, there has to be a way to repair an index. Period.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-555) Index Corruption

Sebastian Nagel (Jira)
In reply to this post by Sebastian Nagel (Jira)
    [ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12445537 ]
           
Michael McCandless commented on LUCENE-555:
-------------------------------------------

Phew!  OK, thanks for bringing closure to this.

> Index Corruption
> ----------------
>
>                 Key: LUCENE-555
>                 URL: http://issues.apache.org/jira/browse/LUCENE-555
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 1.9
>         Environment: Linux FC4, Java 1.4.9
>            Reporter: dan
>            Priority: Critical
>
> Index Corruption
> >>>>>>>>> output
> java.io.FileNotFoundException: ../_aki.fnm (No such file or directory)
>         at java.io.RandomAccessFile.open(Native Method)
>         at java.io.RandomAccessFile.<init>(RandomAccessFile.java:204)
>         at org.apache.lucene.store.FSIndexInput$Descriptor.<init>(FSDirectory.java:425)
>         at org.apache.lucene.store.FSIndexInput.<init>(FSDirectory.java:434)
>         at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324)
>         at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:56)
>         at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129)
>         at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674)
>         at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658)
>         at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517)
> >>>>>>>>> input
> - I open an index, I read, I write, I optimize, and eventually the above happens. The index is unusable.
> - This has happened to me somewhere between 20 and 30 times now - on indexes of different shapes and sizes.
> - I don't know the reason. But, the following requirement applies regardless.
> >>>>>>>>> requirement
> - Like all modern database programs, there has to be a way to repair an index. Period.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12