Thanks for that. Cheers,
Ted On 8 July 2010 23:12, Shai Erera <ser...@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 <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 > >>> > >> > >> > > > -- Ted McFadden Chief Engineer Leximancer Pty Ltd Queensland, Australia http://www.leximancer.com
