I don't know the details of how lock files are unreliable over NFS, only
that they are. The window of vulnerability, when the lock file is used,
is when one JVM is opening all of the files in an index, and another is
completing an update at the same time. If the updating machine removes
some files after the opening machine has read the 'segments' file but
before it has opened all of the files, then the open will fail with a
FileNotFound exception. If your application can guarantee that indexes
are not opened while an update is completing (under IndexWriter.close()
or IndexReader.close() for deletions) then this will not be a problem.
Doug
Morus Walter wrote:
> Doug Cutting writes:
>
>
>>>Can I have a lucene index on a NFS filesystem without problems
>>>(access is readonly)?
>>
>>So long as all access is read-only, there should not be a problem. Keep
>>in mind however that lock files are known to not work correctly over NFS.
>>
>
> Hmm. Sorry, I was a bit unprecise (at least in the quoted part) so I'm
> not sure, if I got that correctly. Access over NFS is readonly, but
> there would be write access on the NFS server itself (local filesystem).
> Is this ok? Or should I use a "update a copy of the index and exchange
> indexes afterwards" strategy?
>
> TIA
> Morus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>
|