Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@www.apache.org Received: (qmail 80216 invoked from network); 11 Jan 2005 22:17:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 11 Jan 2005 22:17:50 -0000 Received: (qmail 40224 invoked by uid 500); 11 Jan 2005 22:17:42 -0000 Delivered-To: apmail-jakarta-lucene-user-archive@jakarta.apache.org Received: (qmail 40158 invoked by uid 500); 11 Jan 2005 22:17:42 -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 40082 invoked by uid 99); 11 Jan 2005 22:17:41 -0000 X-ASF-Spam-Status: No, hits=1.0 required=10.0 tests=SPF_HELO_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from keyserver.Rescomp.Berkeley.EDU (HELO rescomp.berkeley.edu) (169.229.70.167) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 11 Jan 2005 14:17:40 -0800 Received: by rescomp.berkeley.edu (Postfix, from userid 1007) id DD7FE5B787; Tue, 11 Jan 2005 14:16:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rescomp.berkeley.edu (Postfix) with ESMTP id DA57C7F467; Tue, 11 Jan 2005 14:16:32 -0800 (PST) Date: Tue, 11 Jan 2005 14:16:32 -0800 (PST) From: Chris Hostetter Sender: hossman@hal.rescomp.berkeley.edu To: Lucene Users List , Chris Lamprecht Subject: Re: How do I unlock? In-Reply-To: <88c6a6720501111328667df3c3@mail.gmail.com> Message-ID: References: <41E44366.2070207@apache.org> <88c6a6720501111328667df3c3@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N : What about a shutdown hook? Interesting idea, at the moment the file is created on disk, the FSDirectory could add a shutdown hook that checked for the existence of the file and if it's still there (implying that the Lock owner failed without releasing the lock) it can forcably remove it. Of course: this assumes that LockFiles are never shared between processes -- ie: if client A is waiting on a lock that client B is holding, does the lock A eventually gets use the same file that B's lock was using, or does the old lock file get deleted and a new one created ? (I don't really understand a lot of Lucene's locking code) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-user-help@jakarta.apache.org