You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Michael McCandless (JIRA)" <ji...@apache.org> on 2008/07/11 20:48:31 UTC

[jira] Resolved: (LUCENE-1328) FileNotFoundException in

     [ https://issues.apache.org/jira/browse/LUCENE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael McCandless resolved LUCENE-1328.
----------------------------------------

    Resolution: Invalid

I think this came down to not closing IndexSearchers...

> 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@ls20-bc1-14.build.redhat.com) (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@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org