[
https://issues.apache.org/jira/browse/LUCENE-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985920#action_12985920
]
Shai Erera commented on LUCENE-2418:
------------------------------------
Ok, last thing I try (unassign) in hope it will make the close/resolve
re-appear, but nada.
So in case someone takes a look at it in the future:
THIS ISSUE IS A DUP OF 2421 AND NEEDS TO BE CLOSED AS SUCH !!!
> 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: [email protected]
For additional commands, e-mail: [email protected]
