Otis Gospodnetic wrote:
Hi,

Actually, I quite-like and agree with Marvin's suggestion.  If NFS 4 indeed does work 
well with Lucene, and NFS 3 does not, then I think it's reasonable to expect people to 
get NFS 4 to make their Lucene apps work correctly with them.  Maybe I got lost in this 
thread, but it sounds like there are a lot of tricky scenarios ("oh, you can do X, 
but then if Y happened, we need to make sure not to do Z..."), so we also need to 
think about code complexity for the ease of debugging, and further development of the 
Lucene core by as many people as possible.

What I like about Marvin's proposed deletion policy is when Lucene is
running against an NFS client + server pair that indeed supports
locking, the deletion would then be nearly "perfect" (index files are
deleted the moment they are not in use, depending on whether reader is
allowed to delete).

But what I don't like about it is it doesn't "gracefully degrade" to
the common NFS case where locking does not work.  And, this is often
outside our user's control.  So not offering a workable solution that
doesn't require NFS locks will only hurt our users.

But the good news is since we will allow subclassing to make your own
deletion policy, we can eventually do both of these approaches and our
users can pick one or do their own.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to