jira at apache
Jul 14, 2008, 1:12 PM
Post #1 of 2
(575 views)
Permalink
|
|
[jira] Commented: (LUCENE-1328) FileNotFoundException in
|
|
[ 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 (brewbuilder [at] ls20-bc1-14) (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: java-dev-unsubscribe [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene
|
