lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (LUCENE-2418) NativeFSLock should allow for the existence of the lock file, if it was released successfully but fails to delete
Date Mon, 24 Jan 2011 19:24:43 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Shai Erera reassigned LUCENE-2418:
----------------------------------

    Assignee:     (was: Shai Erera)

> NativeFSLock should allow for the existence of the lock file, if it was released successfully
but fails to delete
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2418
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2418
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>            Reporter: Shai Erera
>            Priority: Minor
>
> When running JUnit tests, sometimes NativeFSLock.release() throws an exception because
it cannot delete the test lock file. After some investigation it seems that NativeFSLock should
relax its policy around the existence of the lock file (whether the regular or the test one):
> * Even if it's the slimmest of chances, two JVMs can draw the same random lock file (as
happened during the JUnit tests) and then one of them will fail to delete it, because the
file will be deleted by one JVM, and File.delete() returns false if the file does not exist.
> * Between the lock is released and a delete() is attempted, some external process like
AntiVirus, may hold the file, prevent its deletion.
> Unlike SimpleFSLock, the existence of the native lock should not prevent one from obtaining
it. Therefore, the following changes are proposed:
> * release() is allowed to fail to delete the lock file.
> * obtain() should not return false if the lock file exists - it should really attempt
to obtain it.
> * in acquireTestLock(), if after release() is called the lock file still exists, we'll
retry the delete few ms later, and if that fails, call deleteOnExit.
> ** The only reason to do that is for 'niceness' -- we don't want to pollute the filesystem
w/ random lock files. W/ the regular lock file there's no problem, because the next obtain()
will operate on the same lock file, always.

-- 
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message