DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11109>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11109
Search lock file location should be configurable and favored over disableLuceneLocks property
Summary: Search lock file location should be configurable and
favored over disableLuceneLocks property
Product: Lucene
Version: CVS Nightly - Specify date in submission
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Search
AssignedTo: lucene-dev@jakarta.apache.org
ReportedBy: aguenther@collab.net
[Currently]
We're using Lucene as part of one of our components in a Unix environment and
components might run under different UIDs. In our specific case component A
creates the index folder and component B is performing the search in the same
folder. Folders are readable but for security reasons write protected except for
the indexing component. This is a problem for us since Lucene writes commit.lock
files during search. I recently noticed the following enhancement in CVS:
--FROM LUCENE CHANGES.TXT-->
1.3 DEV1
3. Added the ability to disable lock creation by using disableLuceneLocks
system property. This is useful for read-only media, such as CD-ROMs.
(otis)
<--END
This wouldn't solve our problem because then indexing can corrupt a search
running at the same time.
[Desired proposal]
I rather would appreciate another property that let's me specify a separate and
writable folder for each indexing log file. Read-only media, such as CD-Roms
might even use a /tmp folder .e.g. then. Currently the name is commit.lock. It
probably has to be slightly different to be able to associate lock files with
indexing folders. Therefore, I even suggest to encourage using these over the
disableLuceneLocks.
[Question]
We recently upgraded to 1.2, which let's me assume that 1.3 is far away ;( Is
that correct and what will be the date.
Thanks for consideration,
Andreas
--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11109>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11109
Search lock file location should be configurable and favored over disableLuceneLocks property
Summary: Search lock file location should be configurable and
favored over disableLuceneLocks property
Product: Lucene
Version: CVS Nightly - Specify date in submission
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Search
AssignedTo: lucene-dev@jakarta.apache.org
ReportedBy: aguenther@collab.net
[Currently]
We're using Lucene as part of one of our components in a Unix environment and
components might run under different UIDs. In our specific case component A
creates the index folder and component B is performing the search in the same
folder. Folders are readable but for security reasons write protected except for
the indexing component. This is a problem for us since Lucene writes commit.lock
files during search. I recently noticed the following enhancement in CVS:
--FROM LUCENE CHANGES.TXT-->
1.3 DEV1
3. Added the ability to disable lock creation by using disableLuceneLocks
system property. This is useful for read-only media, such as CD-ROMs.
(otis)
<--END
This wouldn't solve our problem because then indexing can corrupt a search
running at the same time.
[Desired proposal]
I rather would appreciate another property that let's me specify a separate and
writable folder for each indexing log file. Read-only media, such as CD-Roms
might even use a /tmp folder .e.g. then. Currently the name is commit.lock. It
probably has to be slightly different to be able to associate lock files with
indexing folders. Therefore, I even suggest to encourage using these over the
disableLuceneLocks.
[Question]
We recently upgraded to 1.2, which let's me assume that 1.3 is far away ;( Is
that correct and what will be the date.
Thanks for consideration,
Andreas
--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>