[jira] Updated: (LUCENE-2418) NativeFSLock should allow for the existence of the lock file, if it was released successfully but fails to delete

["Shai Erera (JIRA)" <ji...@apache.org>]

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

Shai Erera updated LUCENE-2418:
-------------------------------

    Fix Version/s:     (was: 4.0)

For some reason this issue cannot be resolved (resolve/close links don't appear in my JIRA). Removed the Fix Version so that it doesn't bug us.

> 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
>            Assignee: 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