[
https://issues.apache.org/jira/browse/LUCENE-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-6508:
--------------------------------
Attachment: LUCENE-6508.patch
Here is a prototype patch (does not compile, just for looking).
Implements Lock as described above. Directory.obtainLock looks like this:
{code}
/**
* Returns an obtained {@link Lock}.
* @param name the name of the lock file
* @throws IOException if the lock could not be obtained
*/
public abstract Lock obtainLock(String name) throws IOException;
{code}
IndexWriter wraps the directory with a simple DirectoryWrapper, that calls
isValid() on the write.lock before any major destructive operation (e.g.
createOutput, delete, rename) for best-effort safety.
SimpleFS isValid() is mainly implemented by a ctime check. This LockFactory is
interesting because its close() method could potentially release someone else's
lock if stuff has gone wrong. It calls isValid() as best effort detection and
informs the user if the lock file cannot be safely deleted and doesn't try to
delete it. It also informs when things seem ok, but it is unable to delete the
file for some reason.
NativeFS checks all necessary components in isValid(): map entry, lock,
filechannel, os file descriptor, and underlying file ctime. It doesn't need the
careful logic of SimpleFS in close, because nothing external can cause it to
release someone else's lock.
In both cases i tried to improve exception messages and toStrings.
obtain timeout, dangerous loops and discarding exceptions are all removed.
There were two justifications for this:
* claimed sporatic permission denied on mac os X for NativeFSLock
* claimed sporatic access denied on windows for SimpleFSLock
Either these were bugs in our previous locking, or real bugs/crazy behavior in
the JDK or OS. If its the former, we dont need the timeout ever. If its the
latter, lets get specific exceptions and cases and try to dig into what is
wrong. Worst case, we should make Windows/OS X versions of LockFactory for any
wierd stuff like that, and let them take timeout as their own parameter (user
must deal with it). But this should be a LockFactory impl detail. Maybe someone
even wants to make a LockFactory that blocks for some crazy reason (uses
fc.lock instead of .tryLock)
I didnt try cutting over tests yet or other things, that is more work.
> Simplify Directory/lock api
> ---------------------------
>
> Key: LUCENE-6508
> URL: https://issues.apache.org/jira/browse/LUCENE-6508
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Assignee: Uwe Schindler
> Attachments: LUCENE-6508-deadcode1.patch, LUCENE-6508.patch
>
>
> See LUCENE-6507 for some background. In general it would be great if you can
> just acquire an immutable lock (or you get a failure) and then you close that
> to release it.
> Today the API might be too much for what is needed by IW.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
