Marvin Humphrey wrote:
On Oct 31, 2006, at 11:47 AM, Doug Cutting wrote:
I think the need for that would disappear if the lockless commit patch
gets committed. Then there'd be no reason not to put lock files
directly in the index directory, since only writers would need to lock
things.
Unl
On Oct 31, 2006, at 11:47 AM, Doug Cutting wrote:
I think the need for that would disappear if the lockless commit
patch gets committed. Then there'd be no reason not to put lock
files directly in the index directory, since only writers would
need to lock things.
Unless the index is on
Doug Cutting wrote:
> I think the need for that would disappear if the lockless commit patch
> gets committed. Then there'd be no reason not to put lock files
> directly in the index directory, since only writers would need to lock
> things.
Great! and so we also get rid of this risk:
> .. sourc
Doron Cohen wrote:
Not having to assign index readers a write permission in the index dir is a
nice feature, I didn't think of it that way.
I think the need for that would disappear if the lockless commit patch
gets committed. Then there'd be no reason not to put lock files
directly in the i
Not having to assign index readers a write permission in the index dir is a
nice feature, I didn't think of it that way.
I looked at having it the other way around - i.e. that by default locks
would be maintained in the index dir and only when inadequate - like the
readers/writers scenario, allow
I you may be overcomplicating the lock design. Unix never had any OS
file locking at all (until Windows came around...).
If you are going to use Lucene in a high performing multi-user/multi-
server environment, having the Lucene server process control the
locks (i.e. move Lucene API into a s
: Doug explains the rationale here:
:
: http://xrl.us/svsz (Link to mail-archives.apache.org)
That rationale makes a lot of sense for FSDirectory/SimpleLockFactory to
use by default (since it already doesn't work in a distributed disk
system like NFS) but as we start getting other Directory/LockF
On Oct 30, 2006, at 3:12 PM, Doron Cohen wrote:
This would be avoided if index locks are maintained in the index
folder. I
searched the lists for previous discussions on this 'design
decision' -
i.e. where the index locks reside - found none. Wouldn't it simplify
matters to have the locks i
(extracted from issue 665 (turned to be non related to that issue).)
In NFS or other shared fs situations, Locks are maintained in a specified
folder, but a lock file name is derived from the full path of the index
dir, actually the canonical name of this dir. So, if the same index is
accessed by
