lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dan (JIRA)" <>
Subject [jira] Commented: (LUCENE-555) Index Corruption
Date Mon, 24 Apr 2006 20:11:10 GMT
    [ ] 

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

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:
>      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