lucene-dev mailing list archives

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


Shai Erera commented on LUCENE-2421:

bq. Lock factories do not have to work with all other lock 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

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:
>             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:
For additional commands, e-mail:

View raw message