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.
Otis
----- Original Message ----
From: Michael McCandless <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Thursday, January 18, 2007 5:24:16 PM
Subject: Re: Lucene 2.1, soon
Marvin Humphrey wrote:
>
> On Jan 17, 2007, at 1:16 PM, Michael McCandless wrote:
>
> The real problem is NFS. For background, see
> <http://nfs.sourceforge.net/#section_d>, item D2, which deals with NFS
> and "delete on last close".
>
> Now I wonder. Version 4 of the NFS protocol introduces state, so it's
> possible to implement file locking. Can we lock a segments file, then
> have IndexFileDeleter detect which segments are locked that way? And if
> that's the case, can we detect whether the locking mechanism is failing
> and throw an exception if someone tries to use an earlier version of NFS?
Locking and NFS makes me very nervous :)
> I'd be cool with making it impossible to put an index on an NFS volume
> prior to version 4. That puts the blame where it belongs.
Well, most times users have no control over which NFS server and/or
client version is in use, so I think taking this approach of "pinning
the blame" can only hurt our users. I would rather find a solution
that's more portable, if we can (like the ref counting idea Chuck
brought up).
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
