Stas, Would you be able/willing to share that improved Directory with the list?
Regards, Terry ----- Original Message ----- From: "Stas Chetvertkov" <[EMAIL PROTECTED]> To: "Lucene Users List" <[EMAIL PROTECTED]> Sent: Friday, October 11, 2002 12:33 PM Subject: Re: FileNotFoundException while indexing > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
