Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 17372 invoked from network); 19 Jul 2006 21:49:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Jul 2006 21:49:28 -0000 Received: (qmail 11258 invoked by uid 500); 19 Jul 2006 21:49:23 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 11235 invoked by uid 500); 19 Jul 2006 21:49:23 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 11217 invoked by uid 99); 19 Jul 2006 21:49:23 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jul 2006 14:49:23 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [66.111.4.28] (HELO out4.smtp.messagingengine.com) (66.111.4.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jul 2006 14:49:22 -0700 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 70E79D909D3 for ; Wed, 19 Jul 2006 17:49:00 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by frontend3.internal (MEProxy); Wed, 19 Jul 2006 17:49:03 -0400 X-Sasl-enc: 0ow02JKH3NQKdVP3ijxdcPbEPAD47pMQX/R8wCGqtlJy 1153345742 Received: from [10.17.4.3] (pool-72-70-33-84.bstnma.fios.verizon.net [72.70.33.84]) by mail.messagingengine.com (Postfix) with ESMTP id D1274203C for ; Wed, 19 Jul 2006 17:49:02 -0400 (EDT) Message-ID: <44BEA8CB.2020604@mikemccandless.com> Date: Wed, 19 Jul 2006 17:48:59 -0400 From: Michael McCandless User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: java-user@lucene.apache.org Subject: Re: NFS/iSCSI SAN with Lucene References: <13F36D2926AD444697093282F20041B704A8BDC4@buf-ex01.cymfony.com> In-Reply-To: <13F36D2926AD444697093282F20041B704A8BDC4@buf-ex01.cymfony.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N > I did a search on the Lucene list archives, found a lot of posts about > the use of Lucene with NFS and how there are locking issues, but don't > see anybody coming to a real solution to this. We are trying to fix this. Many people seem to hit it. The current plan is to first decouple the Locking implementation from the Directory implementation: http://issues.apache.org/jira/browse/LUCENE-305 and then create a Locking implementation that uses native OS locks instead of the simple file-existence locks (used now) that do not work with NFS. But the development is still in process and so it won't be until a future Lucene release that this is fixed correctly. A very good workaround is to use or be inspired by the approach that the Solr project: http://incubator.apache.org/solr/features.html http://incubator.apache.org/solr/tutorial.html uses, described here: http://wiki.apache.org/solr/CollectionDistribution The gist is, your single Java process that has an IndexWriter periodically snapshots the index at a known-safe time, and then the multiple Searchers switch to the latest snapshot once the snapshot is complete. Solr actually distributes copies of the index to each Searcher's local storage, but you could probably modify this approach so that, instead, the Searchers all share a single copy off your SAN. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org