lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted McFadden <...@leximancer.com>
Subject Re: Issue Lucene-2421 and NativeFSLockFactory.clearLock behaviour?
Date Thu, 08 Jul 2010 13:23:27 GMT
Thanks for that.

Cheers,

Ted


On 8 July 2010 23:12, Shai Erera <serera@gmail.com> wrote:

> 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
> >>>
> >>
> >>
> >
>



-- 
Ted McFadden
Chief Engineer

Leximancer Pty Ltd
Queensland, Australia
http://www.leximancer.com

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