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]
