I don't really know/understand a lot about the current internals of Lucene
Locking ... but based on the writeup you've added to Jira, your plan of
attack seems like a sound refactoring approach.
Your choice to use explicit setters instead of a system properties seems
to make sense given some of the other semi-recent API changes to eliminate
the use of system props in lucene (personally i think having both setters
and system props is cool ... but it doesn't seem like anything about your
approach would prevent a irectory implimentation from using a sys prop if
it wanted to)
Yes, this is very much a refactoring, for starters. After this I'd
like to create a NativeFSLockFactory that uses native OS locks to
prevent the "lock timeout" errors when the JVM previously had a hard
shutdown and to work across remote filesystems (though there's at
least one case where this may not have worked correctly over NFS; not
sure about Samba mount).
If that proves reliable we could eventually make it the default
locking for FSDirectory.
I like the idea of both setters & system props. So, if the setter is
called, we use that LockFactory. Else, if a system prop is set, we
use that LockFactory. Else we fallback to the original default
LockFactory implementation (to keep backwards compatibility). I'll
take this approach.
Also: apparently Jira does not allow issues to be renamed? I had
wanted to rename LUCENE-305 this "decouple locking implementation from
directory implementation".
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
