[ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376090 ]
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$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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
