lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] Updated: (LUCENE-2421) Hardening of NativeFSLock
Date Sat, 01 May 2010 04:26:53 GMT


Shai Erera updated LUCENE-2421:

    Attachment: LUCENE-2421.patch

Patch adds throwin ThreadInterruptedException.

About using MXBean name, I wrote this code:
String name = "d:/temp/file-" + ManagementFactory.getRuntimeMXBean().getName();
new File(name).createNewFile();
System.out.println(new File(name).exists());

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?

> Hardening of NativeFSLock
> -------------------------
>                 Key: LUCENE-2421
>                 URL:
>             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:
For additional commands, e-mail:

View raw message