DO NOT REPLY [Bug 11109] New: - Search lock file location should be configurable and favored over disableLuceneLocks property

[bu...@apache.org]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>