[
https://issues.apache.org/jira/browse/LUCENE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862994#action_12862994
]
Uwe Schindler commented on LUCENE-2421:
---------------------------------------
bq. The file created included the @ character, which is valid on Windows (and
also verified on Linux). But I'm still not sure about using it, because if a
system returns a character that is not a valid file character, we may not get
the same file name we think ... so maybe if we still want to use it, we should
move it to the end of the string, so that the name includes the random number
for sure ... what do you think?
I suggested on IRC to take the output of getName() and do a regexp replace and
replace all non ACSII-digit chars:
{code}
ManagementFactory.getRuntimeMXBean().getName().replaceAll("[^a..zA..Z0..9]","")
{code}
Or alternatively simply use the hashCode of that String (but that is less
unique).
> 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
>
> Attachments: LUCENE-2421.patch, LUCENE-2421.patch
>
>
> 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
