[
https://issues.apache.org/jira/browse/LUCENE-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531308
]
Michael McCandless commented on LUCENE-1011:
--------------------------------------------
Using the lock verifier above, I discovered something shocking (to
me): NativeFSLockFactory is in general NOT RELIABLE for locking over
NFS, while SimpleFSLockFactory is reliable modulo the "fails to delete
on exit/crash" minor issue.
This is unexpected because the whole reason we originally created
NativeFSLockFactory was to improve locking over "challenging"
filesystems like NFS. The spooky comment in Sun's javadocs on using
File.createNewFile for locking (which is what SimpleFSLockFactory
uses) drove this:
http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#createNewFile()
But then I remembered Marvin's comment about this:
http://issues.apache.org/jira/browse/LUCENE-710#action_12466911
And on following that lead, indeed, that comment "Note: this method
should not be used for file-locking, as the resulting protocol cannot
be made to work reliably" is only referring to the fact that you
cannot reliably guarantee this lock file will be properly removed.
In testing in my NFS area (mix of Linux & OS X), I see
NativeFSLockFactory sometimes (rarely) allowing a lock to be
double-acquired. Whereas after stress testing SimpleFSLockFactory for
a looong time, it never allows that.
So the NFS challenge/saga continues: now, you should in fact use
SimpleFSLockFactory, and work around the fact that you will sometimes
have to manually remove lock files (it is the lesser of evils).
> Two or more writers over NFS can cause index corruption
> -------------------------------------------------------
>
> Key: LUCENE-1011
> URL: https://issues.apache.org/jira/browse/LUCENE-1011
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1, 2.2, 2.3, 2.4, 2.9
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 2.3
>
> Attachments: LUCENE-1011.patch
>
>
> When an index is used over NFS, and, more than one machine can be a
> writer such that they swap roles quickly, it's possible for the index
> to become corrupt if the NFS client directory cache is stale.
> Not all NFS clients will show this. Very recent versions of Linux's
> NFS client do not seem to show the issue, yet, slightly older ones do,
> and the latest Mac OS X one does as well.
> I've been working with Patrick Kimber, who provided a standalone test
> showing the problem (thank you Patrick!). This came out of this
> thread:
>
> http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=50680;page=1;sb=post_latest_reply;so=ASC;mh=25;list=lucene
> Note that the first issue in that discussion has been resolved
> (LUCENE-948). This is a new issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
