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