lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2421) Hardening of NativeFSLock
Date Tue, 05 Oct 2010 15:16:35 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918019#action_12918019
] 

Michael McCandless commented on LUCENE-2421:
--------------------------------------------

So, I'm confused on how/why the *test* lock name would get a conflict
with multiple JREs running our unit tests.

Ie, each JRE runs tests in certain index directories.  And the test
lock is acquired in the index directory.  So, if tests running in
different JREs are sharing the same index directory, then more serious
problems will ensue.

I think it must have only been the test output formatter
(LuceneJUnitResultFormatter) that was conflicting on the test lock
name.  Because this is the only locking usage that'd be sharing the
same lock dir across JREs...


> 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: 2.9.3, 3.0.2, 3.1, 4.0
>
>         Attachments: LUCENE-2421-2.patch, LUCENE-2421.patch, LUCENE-2421.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message