lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marvin Humphrey (JIRA)" <>
Subject [jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors &
Date Fri, 20 Nov 2009 16:56:40 GMT


Marvin Humphrey commented on LUCENE-1877:


I'm a little concerned about the suitability of the polling approach for a
low-level library like Lucene -- shouldn't active code like that live in the
application layer?  Is it possible to exceed the polling interval for a low
priority process on a system under heavy load?  What happens when the app

For removing stale lock files, another technique is to incorporate the host
name and the pid.  So long as you can determine that the lock file belongs to
your machine and that the PID is not active, you can safely zap it.

Then tricky bit is how you get that information into the lock file.  If you
try to write that info to the lock file itself after an O_EXCL open, creating
a fully valid lock file is no longer an atomic operation.  

The approach suggested by the creat(2) man page and endorsed in the Linux NFS
FAQ involves hard links:

    The solution for performing atomic file locking using a lockfile
    is to create a unique file on the same file system (e.g.,
    incorporating hostname and pid), use link(2) to make a link to the
    lockfile. If link() returns 0, the lock is successful. Otherwise,
    use stat(2) on the unique file to check if its link count has
    increased to 2, in which case the lock is also successful. 

This approach should also work on Windows for NTFS file systems since Windows
2000 thanks to the CreateHardLink() function.  (Samba file shares, you're out
of luck.)  However, I'm not sure about the state of support for hard links in

If you're interested in continuing this discussion, we should probably take it
somewhere other than this closed issue.

> Use NativeFSLockFactory as default for new API (direct ctors &
> --------------------------------------------------------------------------
>                 Key: LUCENE-1877
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Javadocs
>            Reporter: Mark Miller
>            Assignee: Uwe Schindler
>             Fix For: 2.9
>         Attachments: LUCENE-1877.patch, LUCENE-1877.patch, LUCENE-1877.patch, LUCENE-1877.patch
> A user requested we add a note in IndexWriter alerting the availability of NativeFSLockFactory
(allowing you to avoid retaining locks on abnormal jvm exit). Seems reasonable to me - we
want users to be able to easily stumble upon this class. The below code looks like a good
spot to add a note - could also improve whats there a bit - opening an IndexWriter does not
necessarily create a lock file - that would depend on the LockFactory used.
> {code}  <p>Opening an <code>IndexWriter</code> creates a lock file
for the directory in use. Trying to open
>   another <code>IndexWriter</code> on the same directory will lead to a
>   {@link LockObtainFailedException}. The {@link LockObtainFailedException}
>   is also thrown if an IndexReader on the same directory is used to delete documents
>   from the index.</p>{code}
> Anyone remember why NativeFSLockFactory is not the default over SimpleFSLockFactory?

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:
For additional commands, e-mail:

View raw message