[
https://issues.apache.org/jira/browse/LUCENE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862973#action_12862973
]
Shai Erera commented on LUCENE-2421:
------------------------------------
bq. Lock factories do not have to work with all other lock factories...you need
to use the same lock factory across all process'.
I agree, but I've grown accustomed here that we try to protect users from their
own mistakes. I.e., if the factory is a parameter to the application, this can
certainly happen, w/o any of the application owners even realize that ... so it
just seems dangerous to me, and I think that the alternative of keeping the
file there and failing elsewhere is not good.
Another scenario - one application opens the index on a local file system
(which is shared) and uses Native, while the other, for safety reason, opens
the index using Simple lock because it reads the index from a remote share ...
does not make a lot of sense - but possible.
bq. or even that the native lock feel needs to be in the same dir (eg it could
be in a tmp dir)
Good point - but it's irrelevant to that issue - one can already shoot himself
in the leg today by doing that. That's something I don't think we can protect
from ... but allowing two lock files in the same directory - that just seems
like a bug. Still, one could impl MyOwnNativeFSLock and create "my.lock.file"
... but we cannot protect from that either. So at least, and that's my own
opinion, the core factories that are provided w/ Lucene should behave well.
So Mark - I agreed w/ you before on that, until Uwe brought up the reason why
NativeFSLock was fixed in 2.9 to use the same lock file as Simple ... it seems
like a good catch to me, and I think if it was fixed once already, do we really
want to break that fix? That will certainly be a bw break, because now
NativeFSLock could obtain a lock if a lock file is there (I'm not sure if we
have tests that cover that scenario, but I have a feeling some will fail if we
change that).
If the result of that discussion is that we should not fail if the lock file
cannot be deleted, then I think we should rename it too, so that Native and
Simple use different files and it is clear that you're using two different LFs,
which is not supported?
> 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
