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 Fri, 30 Apr 2010 18:56:55 GMT


Shai Erera commented on LUCENE-2421:

bq.  Libraries shouldn't be doing things like sleeping on you (for so long)...

Well ... I think they'd appreciate the sleep instead of the immediate exception. Previuosly,
I've been asked by customers to do that in other places. A 100ms sleep is barely noticeable
(being so rare), but an exception definitely is! :)

bq. Isn't it "harmless" if we can't delete it?

No it isn't. I distinguish between two cases: the regular and test lock. For the regular lock,
we've already agreed we cannot leave it behind as it will prevent future locking. For the
test lock I catch the exception in acquireTestLock and call deleteOnExit() suppressing the

bq. you should immediately throw ThreadInterruptedException

ok, thought it'd be harmless here to ignore it since I'm only doing last resort actions. But
if that's common practice now, I will throw the exception.

Thanks for the comments !

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