dan commented on LUCENE-555:
Robert says: "complete fault tolerance" and "automatically recover". Robert, I
used none of these terms. You did. Every database, open source or not, that has
risen in its class, has a method, process, or other means of journaling though
its records to restore it to a consistent, usable state. Some methods are
better than others. But the central point is they all have them.
It doesn't have to be "automatic recover", and it doesn't have to be
"completely fault tolerant". But, yes, it has to be recoverable. There may be
some data loss in the process, but it has to be recoverable. I stand by my
statement firmly: Recovery is a necessary and critical requirement.
If you don't want to hear it from me, then ask your business users. Are your
business users willing to commit meaningful, mission critical data to a
database that has no recovery mechanism? Have you done this? Please do.
Robert says: "Many users and uses of Lucene do not require the complexity, and
performance degradation a complete fault tolerant system would require...." How
you choose RAID it, store it, mirror it, back it up, copy it, is an
implementation choice, and is entirely non sequitur to the basic requirement of
software package performing a recovery process on its own file format. QED
> 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.<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.get(SegmentReader.java:129)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
> 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:
For more information on JIRA, see:
To unsubscribe, e-mail: java-dev-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: java-dev-help@xxxxxxxxxxxxxxxxx