lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 11109] - Search lock file location should be configurable and favored over disableLuceneLocks property
Date Mon, 09 Sep 2002 05:57:56 GMT
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





------- Additional Comments From aguenther@collab.net  2002-09-09 05:57 -------
Otis,
First, I am glad that you responded at all. Second, I am pretty disappointed
about your response, which doesn't really encourage people to participate in
open source development regarding usage and feedback. Recall that it's the user
community, which makes open source successfull and it would be more than polite
trying to understand the outside world using such software. However, I am not
very keen in debating these things since I am more interested in a solution to
our problem.

I probably didn't quite articulate myself and therefore will try to give you a
more detailed description of our situation:

We're using Lucene to index mailing lists. For security reasons indexing is
performed with a different UID than a search. This implies that search has
read-only access to our indexed files as well as the folder they reside in. As
we noticed, Lucene writes lock files during search into the same folder where
these index files are located. To turn off lock files through
'disableLuceneLocks' property doesn't seem to be a reasonable solution to us. At
least you must have had a reason to use a lock for search in the first place,
which I guess is to prevent indexing in between. A proposed solution would be to
specify a different location through a property where Lucene could write its
search lock file to. 

If you have a better solution to our problem, I am more than interested to
listen to it. Otherwise I would appreciate a statement why a property to specify
a different location is out of the question. At least you didn't respond to that.

Thanks for taking your time,
Andreas

--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message