lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: Issue Lucene-2421 and NativeFSLockFactory.clearLock behaviour?
Date Thu, 08 Jul 2010 13:12:53 GMT
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 <serera@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 <serera@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 <ted@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
>>>
>>
>>
>

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