I had experienced similar problem with FileNotFoundExceptions. Our system has one server writing to index (located on NFS mounted disk) and several servers searching in it. In my case, those exceptions were thrown by search servers.
I found out that Lucene locking doesnot work on NFS - in this case 2 different processes can call createNewFile() for the same file and get true as a result, and Lucene relies on this method. Archiving server was merging segments, this caused deletion of some files, and at the same time search server was trying to read those and did not succeed. I solved this problem by implementing my own Directory with reliable makeLock() method. Cheers, Stas. ----- Original Message ----- From: "Craig Walls" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 11, 2002 8:02 PM Subject: FileNotFoundException while indexing > This is my first post to this mailing list, so I hope it works... > > We've been trying to use Lucene as our search solution, but every so > often we get a ton of the following in our log files: > > java.io.FileNotFoundException: > /usr/WebSphere/michaels/search/working/artprints/_xx.fnm (A file or > directory in the path name does not exist.) > at java.io.RandomAccessFile.open(Native Method) > at > java.io.RandomAccessFile.<init>(RandomAccessFile.java(Compiled Code)) > at org.apache.lucene.store.FSDirectory.openFile(Unknown Source) > at org.apache.lucene.store.FSDirectory.openFile(Unknown Source) > at org.apache.lucene.store.FSDirectory.openFile(Unknown Source) > at org.apache.lucene.store.FSDirectory.openFile(Unknown Source) > at org.apache.lucene.index.FieldInfos.<init>(Unknown Source) > at org.apache.lucene.index.SegmentReader.<init>(Unknown Source) > at org.apache.lucene.index.IndexWriter.mergeSegments(Unknown > Source) > at > org.apache.lucene.index.IndexWriter.maybeMergeSegments(Unknown Source) > at org.apache.lucene.index.IndexWriter.addDocument(Unknown > Source) > at > com.michaels.search.ProductIndexer.run(ProductIndexer.java:39) > at com.michaels.search.MasterIndexer.run(MasterIndexer.java:56) > at java.lang.Thread.run(Thread.java:512) > > At first, we thought it was because we had multiple threads trying to > add to the same index. That concerned me a bit because I thought that > the write.lock and commit.lock files would prevent bad things like this > from happening if multiple threads were writing to the same index. > Nevertheless, we now have a single thread doing our indexing and it > seemed to work fine for several days, but this morning we found the same > errors in the log file. > > What would cause this, how can we fix it, and why isn't write.lock and > commit.lock not seeming to help with this? > > A bit more info, if it helps: We are running this within a thread that > is kicked off by a servlet when a certain URL is visited. If an indexer > thread is already in progress, we don't kick off another thread. This is > all running within WebSphere 4, running on AIX. > > Any help would be greatly appreciated. > Thanks, > Craig > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
