lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marvin Humphrey (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1877) Improve IndexWriter javadoc on locking
Date Sun, 30 Aug 2009 21:31:32 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749330#action_12749330
] 

Marvin Humphrey commented on LUCENE-1877:
-----------------------------------------

> Anyone remember why NativeFSLockFactory is not the default over 
> SimpleFSLockFactory?

Wasn't it because native locking is somethings implemented with Fcntl, and
Fcntl locking blows chunks?  Especially for a library rather than an
application.

>From the BSD manpage on Fcntl:

{quote}
This interface follows the completely stupid semantics of System V and IEEE
Std 1003.1-1988 (``POSIX.1'') that require that all locks associated with a
file for a given process are removed when any file descriptor for that file is
closed by that process.  This semantic means that applications must be aware
of any files that a subroutine library may access.  For example if an
application for updating the password file locks the password file database
while making the update, and then calls getpwname(3) to retrieve a record, the
lock will be lost because getpwname(3) opens, reads, and closes the password
database.  The database close will release all locks that the process has
associated with the database, even if the library routine never requested a
lock on the database.  Another minor semantic problem with this interface is
that locks are not inherited by a child process created using the fork(2)
function.  The flock(2) interface has much more rational last close
semantics and allows locks to be inherited by child processes.  Flock(2) is
recommended for applications that want to ensure the integrity of their locks
when using library routines or wish to pass locks to their children...
{quote}

The lockfile may be annoying, but at least it's guaranteed safe on all non-shared
volumes when the OS implements atomic file opening.

Are you folks at least able to clean up orphaned lockfiles if the PID it was created
under is no longer active?

> Improve IndexWriter javadoc on locking
> --------------------------------------
>
>                 Key: LUCENE-1877
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1877
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Javadocs
>            Reporter: Mark Miller
>            Priority: Trivial
>             Fix For: 2.9
>
>
> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message