lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-555) Index Corruption
Date Tue, 25 Apr 2006 17:46:09 GMT
    [ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376306 ] 

dan commented on LUCENE-555:
----------------------------

How about some engineering satire to spell it out for you nerds? [Doesn't apply to you Chuck]

public void businessRealityCheck()
{

boolean myopicEngineerStillDoesntGetIt = true;

while ( myopicEngineerStillDoesntGetIt)
{

case(1)
{
A small business running MySQL has a travelling salesman who trips and pulls the power cord
- the database is corrupt. The cause had nothing to do with the software whatsoever. How does
team MySQL respond? The say with enthusiasm "run this recovery program with these parameters..."
And guess what? It just works! The database is recovered. MySQL moves to the top of the class.
}

case(2)
{
Same scenario. How does team Lucene respond? If you are Robert, you say "I think Dan is way
off base." If you are Otis, you retort "I agree with Robert." And all others sing the chorus.
LOL. You could get a gig at The Comedy Club with this material guys. It's hilarious.
}

if ( case(1) == case(2))
	myopicEngineerStillDoesntGetIt = true;

else
	break;
}

}

I'm off this express train to Pretend Town. Close this issue. Pretend that recovery isn't
critical. And enjoy your train ride home.


> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message