[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
