Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@apache.org Received: (qmail 52098 invoked from network); 11 Oct 2002 16:43:18 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 11 Oct 2002 16:43:18 -0000 Received: (qmail 23470 invoked by uid 97); 11 Oct 2002 16:44:03 -0000 Delivered-To: qmlist-jakarta-archive-lucene-user@jakarta.apache.org Received: (qmail 23441 invoked by uid 97); 11 Oct 2002 16:44:03 -0000 Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Users List" Reply-To: "Lucene Users List" Delivered-To: mailing list lucene-user@jakarta.apache.org Received: (qmail 23429 invoked by uid 98); 11 Oct 2002 16:44:02 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <00f701c27145$30034d00$0201a8c0@netframe.com> From: "Terry Steichen" To: "Lucene Users List" References: <3DA6F608.FA6DF24D@michaels.com> <01ec01c27143$fc57df80$d667a8c0@STASNOTEBOOK> Subject: Re: FileNotFoundException while indexing Date: Fri, 11 Oct 2002 12:42:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stas, Would you be able/willing to share that improved Directory with the list? Regards, Terry ----- Original Message ----- From: "Stas Chetvertkov" To: "Lucene Users List" 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" > To: > 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.(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.(Unknown Source) > > at org.apache.lucene.index.SegmentReader.(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: > > > For additional commands, e-mail: > > > > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: