Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@apache.org Received: (qmail 76942 invoked from network); 20 Aug 2003 23:08:14 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 20 Aug 2003 23:08:14 -0000 Received: (qmail 17256 invoked by uid 97); 20 Aug 2003 20:24:15 -0000 Delivered-To: qmlist-jakarta-archive-lucene-user@nagoya.betaversion.org Received: (qmail 17247 invoked from network); 20 Aug 2003 20:24:15 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 20 Aug 2003 20:24:15 -0000 Received: (qmail 57521 invoked by uid 500); 20 Aug 2003 20:12:11 -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 57418 invoked from network); 20 Aug 2003 20:12:09 -0000 Received: from sccrmhc11.comcast.net (204.127.202.55) by daedalus.apache.org with SMTP; 20 Aug 2003 20:12:09 -0000 Received: from lucene.com (12-210-200-74.client.attbi.com[12.210.200.74](untrusted sender)) by comcast.net (sccrmhc11) with SMTP id <2003082020080501100qg8jve>; Wed, 20 Aug 2003 20:08:05 +0000 Message-ID: <3F43D523.70509@lucene.com> Date: Wed, 20 Aug 2003 13:08:03 -0700 From: Doug Cutting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lucene Users List Subject: Re: Lucene Index on NFS Server References: <16167.53762.766191.172922@morus.xipolis.net> <3F296DF1.5050802@lucene.com> <16170.1543.335095.507678@morus.xipolis.net> In-Reply-To: <16170.1543.335095.507678@morus.xipolis.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I don't know the details of how lock files are unreliable over NFS, only that they are. The window of vulnerability, when the lock file is used, is when one JVM is opening all of the files in an index, and another is completing an update at the same time. If the updating machine removes some files after the opening machine has read the 'segments' file but before it has opened all of the files, then the open will fail with a FileNotFound exception. If your application can guarantee that indexes are not opened while an update is completing (under IndexWriter.close() or IndexReader.close() for deletions) then this will not be a problem. Doug Morus Walter wrote: > Doug Cutting writes: > > >>>Can I have a lucene index on a NFS filesystem without problems >>>(access is readonly)? >> >>So long as all access is read-only, there should not be a problem. Keep >>in mind however that lock files are known to not work correctly over NFS. >> > > Hmm. Sorry, I was a bit unprecise (at least in the quoted part) so I'm > not sure, if I got that correctly. Access over NFS is readonly, but > there would be write access on the NFS server itself (local filesystem). > Is this ok? Or should I use a "update a copy of the index and exchange > indexes afterwards" strategy? > > TIA > Morus > > --------------------------------------------------------------------- > To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org > For additional commands, e-mail: lucene-user-help@jakarta.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-user-help@jakarta.apache.org