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 Wed, 07 Jul 2010 16:28:30 GMT
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