I committed a fix earlier today. clearLock will fail if the lock cannot be released (meaning someone else holds it), however ignore the result of file.delete().
Shai On Wed, Jul 7, 2010 at 7:41 PM, Shai Erera <ser...@gmail.com> wrote: > Double-checking the code, this isn't that simple :). Someone can call > clearLock while the lock is held (for some unknown reason), in which case we > do want to signal failure. The clearLock jdoc specifies that it forcefully > unlocks and removes the lock ... > > Currently, the method does not unlock anything - just attempts to remove > the lock. If the lock is still held, it will fail w/ the exception ... so > there are two cases: > 1) You call clearLock w/o calling IndexWriter.unlock() first, and the lock > is held by another process --> here you wouldn't want to method to silently > fail, because an attempt to lock the Directory would fail, which will be > confusing. > 2) The lock is not used, either 'cause you call IW.unlock(), however there > is an external process that holds the lock, preventing its delete(). Here > you wouldn't care if the method silently fails ... > > I guess what we should do is try to forcefully unlock it first, and if that > succeeds then delete the lock file, ignoring the returned output. Or change > the javadocs. > > I'll check it > > Shai > > > On Wed, Jul 7, 2010 at 7:28 PM, Shai Erera <ser...@gmail.com> wrote: > >> Yes, looks like clearLock should be changed to not throw the exception, >> but rather do a best effort - call delete() but don't respond to its return >> value. I'll change that on 3x, I'm not sure if a backport to 3.0.x is needed >> (doesn't seem to justify a 3.0.3 ...) >> >> Shai >> >> >> On Wed, Jul 7, 2010 at 8:59 AM, Ted McFadden <t...@leximancer.com> wrote: >> >>> Hi, >>> >>> For Lucene 3.0.2, issue LUCENE-2421 ( >>> https://issues.apache.org/jira/browse/LUCENE-2421) changed >>> NativeFSLock.release to not raise an exception if a write.lock file could >>> not be deleted since the presence of the file itself does not mean a lock >>> is >>> held. >>> >>> Should NativeFSLockFactory.clearLock also be changed to not raise an >>> exception if it can't delete the write.lock file? The comments in the >>> clearLock method seem to suggest the method is really no longer >>> necessary, >>> but IndexWriter.init can still call it. >>> >>> If the write.lock is held from deletion by antivirus or something as >>> described in LUCENE-2421, IndexWriter construction looks like it can fail >>> unnecessarily for the same reason: >>> >>> IndexWriter >>> IndexWriter.init >>> Directory.clearLock >>> NativeFSLockFactory.clearLock: >>> ... >>> if (lockFile.exists() && !lockFile.delete()){ >>> throw new IOException("Cannot delete " + lockFile); >>> } >>> >>> >>> We have seen this exception path once in the wild (on a Windows box). >>> >>> I can work around this with a custom LockFactory but thought I should >>> check >>> if I'm reading the code right. >>> >>> Cheers, >>> >>> Ted >>> >>> >>> -- >>> Ted McFadden >>> Chief Engineer >>> >>> Leximancer Pty Ltd >>> Queensland, Australia >>> http://www.leximancer.com >>> >> >> >
