[ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376331 ]
Chuck Williams commented on LUCENE-555: --------------------------------------- Dan, I don't know if you are still watching this, but in addition to Doug's point about how Lucene changes, there is a second important consideration to keep in mind. Lucene is a search library, not an enterprise search application. If you are looking for the latter, you might want to check out something like SOLR. The existence of SOLR demonstrates the difference. There are many successful applications based on Lucene for a wide range of uses. Many major products and web sites are based on Lucene. As Lucene is a library, it supports a wide range of use cases. The beauty of the library is that it is solid, robust, well exercised through use and open source review/contribution, and is well-designed for specialization into different applications. Journaling and recovery are useful capabilities, but I hold to the position that the job of the library is to never corrupt the index. Journalizing and recovery should be optional add-ons for those applications that need them. For my current application, for example, total index corruption can be resolved by reindexing from an external persistent repository. My one requirement is to know if data is lost, and if it is a small amount of data, to be able to identify what was lost. Whence, a limited journaling capability that focuses on recovery of data held in RAM and not yet committed to disk when a crash occurs. What you found is a bug in optimize, a quite surprising one at that. Please take the time to help track it down. > 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]
