Hardening of NativeFSLock
-------------------------
Key: LUCENE-2421
URL: https://issues.apache.org/jira/browse/LUCENE-2421
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Shai Erera
Assignee: Shai Erera
Fix For: 3.1
NativeFSLock create a test lock file which its name might collide w/ another
JVM that is running. Very unlikely, but still it happened a couple of times
already, since the tests were parallelized. This may result in a false
exception thrown from release(), when the lock file's delete() is called and
returns false, because the file does not exist (deleted by another JVM
already). In addition, release() should give a second attempt to delete() if it
fails, since the file may be held temporarily by another process (like
AntiVirus) before it fails. The proposed changes are:
1) Use ManagementFactory.getRuntimeMXBean().getName() as part of the test lock
name (should include the process Id)
2) In release(), if delete() fails, check if the file indeed exists. If it is,
let's attempt a re-delete() few ms later.
3) If (3) still fails, throw an exception. Alternatively, we can attempt a
deleteOnExit.
I'll post a patch later today.
--
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
