lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chuck Williams (JIRA)" <>
Subject [jira] Commented: (LUCENE-555) Index Corruption
Date Tue, 25 Apr 2006 20:00:03 GMT
    [ ] 

Chuck Williams commented on LUCENE-555:


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

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:
>      Project: Lucene - Java
>         Type: Bug

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

> Index Corruption
> >>>>>>>>> output
> ../_aki.fnm (No such file or directory)
>         at Method)
>         at<init>(
>         at$Descriptor.<init>(
>         at<init>(
>         at
>         at org.apache.lucene.index.FieldInfos.<init>(
>         at org.apache.lucene.index.SegmentReader.initialize(
>         at org.apache.lucene.index.SegmentReader.get(
>         at org.apache.lucene.index.SegmentReader.get(
>         at org.apache.lucene.index.IndexWriter.mergeSegments(
>         at org.apache.lucene.index.IndexWriter.mergeSegments(
>         at org.apache.lucene.index.IndexWriter.optimize(
> >>>>>>>>> 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:
For additional commands, e-mail:

View raw message