lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Reopened: (LUCENE-678) [PATCH] LockFactory implementation based on OS native locks (java.nio.*)
Date Thu, 19 Oct 2006 02:32:38 GMT
     [ ]

Michael McCandless reopened LUCENE-678:

      Assignee: Michael McCandless  (was: Yonik Seeley)

> [PATCH] LockFactory implementation based on OS native locks (java.nio.*)
> ------------------------------------------------------------------------
>                 Key: LUCENE-678
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Store
>    Affects Versions: 2.1
>            Reporter: Michael McCandless
>         Assigned To: Michael McCandless
>            Priority: Minor
>             Fix For: 2.0.1
>         Attachments: LUCENE-678-patch.txt
> The current default locking for FSDirectory is SimpleFSLockFactory.
> It uses for its locking, which has this
> spooky warning in Sun's javadocs:
>     Note: this method should not be used for file-locking, as the
>     resulting protocol cannot be made to work reliably. The FileLock
>     facility should be used instead.
> So, this patch provides a LockFactory implementation based on FileLock
> (using java.nio.*).
> All unit tests pass with this patch, on OS X (10.4.8), Linux (Ubuntu
> 6.06), and Windows XP SP2.
> Another benefit of native locks is the OS automatically frees them if
> the JVM exits before Lucene can free its locks.  Many people seem to
> hit this (old lock files still on disk) now.
> I've created this new class:
> and added a couple test cases to the existing TestLockFactory.
> I've left SimpleFSLockFactory as the default locking for FSDirectory
> for now.  I think we should get some usage / experience with
> NativeFSLockFactory and then later on make it the default locking
> implementation?
> I also tested changing FSDirectory's default locking to
> NativeFSLockFactory and all unit tests still pass (on the above
> platforms).
> One important note about locking over NFS: some NFS servers and/or
> clients do not support it, or, it's a configuration option or mode
> that must be explicitly enabled.  When it's misconfigured it's able to
> take a long time (35 seconds in my case) before throwing an exception.
> To handle this, I acquire & release a random test lock on creating the
> NativeFSLockFactory to verify locking is configured properly.
> A few other small changes in the patch:
>     - Added a "failure reason" to so that in
>       obtain(lockWaitTimeout), if there is a persistent IOException
>       in trying to obtain the lock, this can be messaged & included in
>       the "Lock obtain timed out" that's raised.
>     - Corrected javadoc in SimpleFSLockFactory: it previously said the
>       wrong system property for overriding lock class via system
>       properties
>     - Fixed unhandled IOException when opening an IndexWriter for
>       create, if the locks dir does not exist (just added
>       lockDir.exists() check in clearAllLocks method of
>       SimpleFSLockFactory & NativeFSLockFactory.
>     - Fixed a few small unrelated issues with TestLockFactory, and
>       also fixed tests to accept NativeFSLockFactory as the default
>       locking implementation for FSDirectory.
>     - Fixed a typo in javadoc in
>     - Added some more javadoc for the LockFactory.setLockPrefix

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message