lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject Re: Issue Lucene-2421 and NativeFSLockFactory.clearLock behaviour?
Date Wed, 07 Jul 2010 16:41:51 GMT
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
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


On Wed, Jul 7, 2010 at 7:28 PM, Shai Erera <> 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 <> wrote:
>> Hi,
>> For Lucene 3.0.2, issue 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message