lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-678) [PATCH] LockFactory implementation based on OS native locks (java.nio.*)
Date Thu, 19 Oct 2006 21:04:38 GMT
    [ http://issues.apache.org/jira/browse/LUCENE-678?page=comments#action_12443646 ] 
            
Yonik Seeley commented on LUCENE-678:
-------------------------------------

take two committed.  Thanks for keeping on top of this Michael!

> [PATCH] LockFactory implementation based on OS native locks (java.nio.*)
> ------------------------------------------------------------------------
>
>                 Key: LUCENE-678
>                 URL: http://issues.apache.org/jira/browse/LUCENE-678
>             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, LUCENE-678-patch2.txt
>
>
> The current default locking for FSDirectory is SimpleFSLockFactory.
> It uses java.io.File.createNewFile 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:
>   org.apache.lucene.store.NativeFSLockFactory
> 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 Lock.java 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 FieldsReader.java
>     - 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message