Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Message-ID: <11567619.49791272715733711.JavaMail.jira@thor>
Date: Sat, 1 May 2010 08:08:53 -0400 (EDT)
From: "Mark Miller (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-2421) Hardening of NativeFSLock
In-Reply-To: <24749183.5191272547014166.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Mark Miller commented on LUCENE-2421:
-------------------------------------

I'm still confused on the native/simple working together thing - I don't see where native will respect simple's lock? Am I missing something?

Also, its almost more confusing that simple will respect the native lock file, when that file is not even native's actual lock - just its medium for a lock. If they could really work together, why even have a native lock?

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