lucene-dev mailing list archives

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

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

Shai Erera commented on LUCENE-2421:
------------------------------------

I guess that you've missed that on the thread: "_It is possible that two JVMs will attempt
to lock the same Directory, one w/ Native and the other w/ Simple. If we won't check in obtain()
whether the file exists, it might obtain a native lock, while the Directory is actually locked
by another JVM using Simple_". Uwe also mentioned Native was fixed to use the same lock file
name in 2.9 because of that.

Another thing why we cannot leave the lock file behind is because if you e.g. switch from
Native to Simple you won't be able to obtain a lock.

And personally I prefer that if the Directory is not locked then the file won't be there -
even if just for clarity, or because how we've all become used to treat the existence of the
lock file by now. And I'd also hate to add another line to bw section :)

> 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
>
>
> 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