[jira] Issue Comment Edited: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors & FSDir.open)
[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750632#action_12750632
]
Uwe Schindler edited comment on LUCENE-1877 at 9/2/09 12:53 PM:
Final patch.
I implemented additional:
- all FS-based lock factories use the same prefix encoding. They are now
(mostly) compatible. E.g. a lock obtained with NativeFSLockFactory would also
be seen as locked with SimpleFSLockFactory.
- Added LockFactory ctors with no param. The FSDir will set the lockdir to
itsself in this case.
- Added test for LUCENE-1885
- Added note about deprecation of all FSDir related system properties, fixed
some docs
Please test this extensively! I hope, I found all problems.
was (Author: thetaphi):
Final patch.
I implemented additional:
- all FS-based lock factories use the same prefix encoding. They are now
(mostly) compatible. E.g. a lock obtained with NativeFSLockFactory would also
be seen as locked with SimpleFSLockFactory.
- Added LockFactory ctors with no param. The FSDir will set the lockdir to
itsself in this case.
- Added test for LUCENE-1885
Please test this extensively! I hope, I found all problems.
> 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, 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} Opening an IndexWriter creates a lock file for the
> directory in use. Trying to open
> another IndexWriter 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.{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
[jira] Issue Comment Edited: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors & FSDir.open)
[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750563#action_12750563
]
Mark Miller edited comment on LUCENE-1877 at 9/2/09 10:58 AM:
--
heh - my jetlag is full effect - I wasn't looking at the lockdir, I was looking
at:
{code}String lockClassName =
System.getProperty("org.apache.lucene.store.FSDirectoryLockFactoryClass");
{code}
*edit
I'm too tired to be emailing - how about deprecating this one though?
was (Author: markrmil...@gmail.com):
heh - my jetlag is full effect - I wasn't looking at the lockdir, I was
looking at:
{code}String lockClassName =
System.getProperty("org.apache.lucene.store.FSDirectoryLockFactoryClass");
{code}
> 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} Opening an IndexWriter creates a lock file for the
> directory in use. Trying to open
> another IndexWriter 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.{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
[jira] Issue Comment Edited: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors & FSDir.open)
[
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} Opening an IndexWriter creates a lock file for the
> directory in use. Trying to open
> another IndexWriter 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.{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
[jira] Issue Comment Edited: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors & FSDir.open)
[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750425#action_12750425
]
Uwe Schindler edited comment on LUCENE-1877 at 9/2/09 6:12 AM:
---
bq. I think we should also fix NativeLockFactory so that if the write lock is
in the index dir it doesn't generate the large digest in the file name. That
digest is problematic when two different machines access the same physical dir
via different mount names, since that results in different lock file names.
The digest problem is not easy to solve: It happens for all LockFactories if
they are not automatically created (when LockFactory==null). As soon as you
call FSDir.open(..., new SimpleLockFactory(...)) you also get this prefix. It
does not appear, when the FSDir is created by FSDir.getDirectory(), as the
init() method cleans the lockPrefix directly after setting the lockfactory (the
lock factory setter sets the prefix).
The prefix is only important, if the lock is not placed inside the index
directory. The best would be that FSDir would simply return null in
getLockId(), when the LockFactory uses the same path as the Directory. For that
to work, the LockFactory should have a getter for the fs path.
I will try some possibilities and post a patch.
was (Author: thetaphi):
bq. I think we should also fix NativeLockFactory so that if the write lock
is in the index dir it doesn't generate the large digest in the file name. That
digest is problematic when two different machines access the same physical dir
via different mount names, since that results in different lock file names.
The digest problem is not easy to solve: It happens for all LockFactories if
they are not automatically created (when LockFactory==null). As soon as you
cann FSDir.open(..., new SimpleLockFactory(...)) you also get these prefix. It
does not appear, when the FSDir is created by FSDir.getDirectory(), as the
init() method cleans the lockPrefix directly after setting the lockfactory (the
lock factory setter sets the prefix).
The prefix is only important, if the lock is not placed inside the index
directory. The best would be that FSDir would simply return null in getLockId,
when the LockFactory uses the same path as the Directory. For that to work, the
LockFactory should have a getter for the fs path.
I will try some possibilities and post a patch.
> 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
>Priority: Trivial
> Fix For: 2.9
>
> Attachments: 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} Opening an IndexWriter creates a lock file for the
> directory in use. Trying to open
> another IndexWriter 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.{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
