[
https://issues.apache.org/jira/browse/LUCENE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613436#action_12613436
]
Yajun Liu commented on LUCENE-1328:
-----------------------------------
Ok, after adding lots of logging, I finally found the problem. We have a cron
job which deletes old files. Sometimes over the weekend, there are not much
updates of index (We are a B2B web site), so files of old segments were deleted
by the cron job, so it is not a bug.
> FileNotFoundException in
> -------------------------
>
> Key: LUCENE-1328
> URL: https://issues.apache.org/jira/browse/LUCENE-1328
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 2.1
> Environment: OS: Linux version 2.6.9-67.0.1.ELsmp ([EMAIL
> PROTECTED]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)) #1 SMP Fri Nov 30
> 11:57:43 EST 2007
> We use solr 1.2 and the lucene is 2.1.( I don't think this problem has
> anything to do with solr.)
> Reporter: Yajun Liu
>
> I had this problem for a while. here is how I used lucene index:
> 1) I don't use compound file.
> 2) I have a single process and a single thread to update index as index
> updater. The index is really small, the mergefactor is 10.
> After index is updated, the same thread copies the index to a tmp directory,
> validate the index in the tmp directory by:
>
> IndexReader reader = IndexReader.open(tmp_directory);
> reader.close();
> then rename the tmp directory to a snapshot_timestamp;
> 3) the snapshot_timestamp is rsyn to search nodes which DO NOT update index.
> 4) We automatically stop and start index updater and search nodes every
> midnight. (don't ask me why)
> Here is what I observed:
> 1) Not always, sometimes when index updater is started during our automatic
> recycle, we got
> java.io.FileNotFoundException: /var/tmp/index/_gw.fnm (No such file or
> directory)
> at java.io.RandomAccessFile.open(Native Method)
> at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212)
> at
> org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor.<init>(FSDirectory.java:501)
> at
> org.apache.lucene.store.FSDirectory$FSIndexInput.<init>(FSDirectory.java:526)
> at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:440)
> at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:57)
> at
> org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:176)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:157)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:130)
> at org.apache.lucene.index.IndexReader$1.doBody(IndexReader.java:205)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:610)
> at org.apache.lucene.index.IndexReader.open(IndexReader.java:184)
> at org.apache.lucene.index.IndexReader.open(IndexReader.java:157)
> Note each time, the missing file is different. When this happen, the program
> automatically tried to reopen the most recent THREE snapshots and we got the
> same exception for each snapshot. Remember, each of the snapshot was
> validated before it was copied.
> 2) The similar things happened on the search node: the same index which was
> opened OK during last night nodes recycle could not be opened due to the same
> exception. The search node does not update index.
> In my case, the index was "validated" before, and it became invalidate in a
> later time. It seems it happened only when we restart the application. When
> the exception happen, the file did not exist in the index.
> --Yajun
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
