[
https://issues.apache.org/jira/browse/LUCENE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862969#action_12862969
]
Mark Miller commented on LUCENE-2421:
-------------------------------------
bq. I guess that you've missed that on the thread
No, just havn't seen a good reason yet...
{quote} "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.{quote}
Lock factories do not have to work with all other lock factories...you need to
use the same lock factory across all process'.
bq. 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.
Not true - there is no reason both simple and native need to use the same lock
file - or even that the native lock feel needs to be in the same dir (eg it
could be in a tmp dir)
bq. And personally I prefer that if the Directory is not locked then the file
won't be there
You cannot guarantee this in any case. If they cannot be deleted, it cannot be
deleted - but cleanliness is no reason to throw an exception in an event that
is not actually a failure situation.
bq. even if just for clarity, or because how we've all become used to treat the
existence of the lock file by now.
I don't find that persuasive myself...
bq. And I'd also hate to add another line to bw section
but its not a back compat break ...
> 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
