[jira] Updated: (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:all-tabpanel
]
Uwe Schindler updated LUCENE-1877:
--
Attachment: LUCENE-1877.patch
Formatting changes in CHANGES.txt and some minor tweaks.
Also changed the isLocked() method for LUCENE-1885 to shortcut, if no lock file
is present. In this case, without a lockfile it may also be not locked. This
prevent NativeFSLock for creating the lock short time without really using it.
It would be good, if somebody could also test this with strange file systems. I
only tested Windows and Solaris
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,
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} pOpening an codeIndexWriter/code creates a lock file for the
directory in use. Trying to open
another codeIndexWriter/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
[jira] Updated: (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:all-tabpanel
]
Uwe Schindler updated LUCENE-1877:
--
Summary: Use NativeFSLockFactory as default for new API (direct ctors
FSDir.open) (was: Improve IndexWriter javadoc on locking)
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} pOpening an codeIndexWriter/code creates a lock file for the
directory in use. Trying to open
another codeIndexWriter/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
[jira] Updated: (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:all-tabpanel
]
Uwe Schindler updated LUCENE-1877:
--
Priority: Major (was: Trivial)
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
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} pOpening an codeIndexWriter/code creates a lock file for the
directory in use. Trying to open
another codeIndexWriter/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
[jira] Updated: (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:all-tabpanel
]
Uwe Schindler updated LUCENE-1877:
--
Attachment: LUCENE-1877.patch
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} pOpening an codeIndexWriter/code creates a lock file for the
directory in use. Trying to open
another codeIndexWriter/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
[jira] Updated: (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:all-tabpanel
]
Mark Miller updated LUCENE-1877:
Comment: was deleted
(was: Is that a bug? I can't even find that class ...)
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} pOpening an codeIndexWriter/code creates a lock file for the
directory in use. Trying to open
another codeIndexWriter/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
[jira] Updated: (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:all-tabpanel
]
Uwe Schindler updated LUCENE-1877:
--
Attachment: LUCENE-1877.patch
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} pOpening an codeIndexWriter/code creates a lock file for the
directory in use. Trying to open
another codeIndexWriter/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
