[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750549#action_12750549
]
Uwe Schindler edited comment on LUCENE-1877 at 9/2/09 10:35 AM:
----------------------------------------------------------------
Here is the patch:
- SimpleFSLockFactory and NativeFSLockFactory now have the same abstract
superclass providing setLockDir and getLockDir. Using this method, it is
possible for directory instances to detect, if the locks reside in the
directory itsself and so a lock prefix is switched off.
- The isLocked() bug in NativeFSLockFactory (LUCENE-1885) is solved by
implementing what was described in this issue.
- aquireTestLock in NativeFSLockFactory was removed from ctor and only called
for the first makeLock() call. This prevents the LockFactory from creating the
directory when not needed (e.g. opening non-existent index).
I have one idea (which is a new feature): How about providing a ctor to
NativeFSLockFactory and SimpleFSLockFactory without param. When this LF is
added to a FSDir, it would default to set the LockDir to itsself (if
lf.getLockDir()==null) lf.setLockDir(this.directory)). This would prevent users
from always giving the directory twice? Any thoughts, I would like to have that.
Because of the missing lockPrefix for locks inside the directory itsself one
backwards test (TestLockFactory) must be changed in backwards-branch, too.
was (Author: thetaphi):
Here is the patch:
- SimpleFSLockFactory and NativeFSLockFactory now have the same abstract
superclass providing setLockDir and getLockDir. Using this method, it is
possible for directory instances to detect, if the locks reside in the
directory itsself and so a lock prefix is switched off.
- The isLocked() bug in NativeFSLockFactory (LUCENE-1885) is solved by
implementing what was described in this issue.
I have one idea (which is a new feature): How about providing a ctor to
NativeFSLockFactory and SimpleFSLockFactory without param. When this LF is
added to a FSDir, it would default to set the LockDir to itsself (if
lf.getLockDir()==null) lf.setLockDir(this.directory)). This would prevent users
from always giving the directory twice? Any thoughts, I would like to have that.
Because of the missing lockPrefix for locks inside the directory itsself one
backwards test (TestLockFactory) must be changed in backwards-branch, too.
> Use NativeFSLockFactory as default for new API (direct ctors & FSDir.open)
> --------------------------------------------------------------------------
>
> Key: LUCENE-1877
> URL: https://issues.apache.org/jira/browse/LUCENE-1877
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Javadocs
> Reporter: Mark Miller
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1877.patch, LUCENE-1877.patch
>
>
> A user requested we add a note in IndexWriter alerting the availability of
> NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm
> exit). Seems reasonable to me - we want users to be able to easily stumble
> upon this class. The below code looks like a good spot to add a note - could
> also improve whats there a bit - opening an IndexWriter does not necessarily
> create a lock file - that would depend on the LockFactory used.
> {code} <p>Opening an <code>IndexWriter</code> creates a lock file for the
> directory in use. Trying to open
> another <code>IndexWriter</code> on the same directory will lead to a
> {...@link LockObtainFailedException}. The {...@link
> LockObtainFailedException}
> is also thrown if an IndexReader on the same directory is used to delete
> documents
> from the index.</p>{code}
> Anyone remember why NativeFSLockFactory is not the default over
> SimpleFSLockFactory?
--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
