NFS解决方案问题

Question

我们的应用程序使用嵌入式Solr实例进行搜索。数据目录位于NFS上，我无法更改它。Solr的使用非常简单，有一个周期性更新索引的线程，还有几个读取器线程——这些都在一个java进程中。没有发生其他Solr交互。

使用默认的"solrconfig.xml"，我有时会遇到"java.nio.channes.OverlappingFileLockException"。据我所知，原因实际上是"SimpleFSLockFactory"无法正确使用NFS。

问题：

1. 考虑到上面描述的应用程序场景（没有并发的索引修改），NoLockFactory难道还不够吗？使用NoLockFactory有什么缺点吗？如果我设置了NoLockFactory，我会在错误日志中得到一些条目，上面写着"配置警告：锁定被禁用"。为什么该消息会进入错误日志？这真的被认为是一个错误案例吗？为什么？

2. 也许有比使用"NoLockFactory"更好的解决方案？

3. 不确定这是否与NFS有关，但有时（非常罕见）我的索引会损坏，在尝试更新索引时会收到很多"java.io.FileNotFoundException:_I.fdx"。除了手动删除整个索引目录并从头开始之外，没有其他方法可以解决这个问题。为什么会发生这种情况？是否有任何优雅的方法可以自动检测损坏的索引并进行恢复？

Answer 1

在NFS上存储索引很容易出现问题，但如果必须在NFS上运行，我预测这个问题可能是由于没有使用NFSv4或没有正确使用它。NFSv4是第一个支持锁定字节范围的版本；v3（很差）支持整个文件，并且没有运行portmap、rpc.lockd和rpc.statd——这些锁可能只是建议性的（而不是强制性的），但绝对不会被字节范围锁定所覆盖。

java.nio.channels.OverlappingFileLockException表示

Unchecked exception thrown when an attempt is made to acquire a lock on a region of a file 
that overlaps a region already locked by the same Java virtual machine, or when another 
thread is already waiting to lock an overlapping region of the same file.

粗略搜索Lucene邮件列表会返回许多结果，这些结果似乎表明在NFS上使用Lucene（以及扩展的Solr）是个坏主意。

撇开锁定问题不谈，性能可能也会相当糟糕。

我知道这不是你所希望的答案，但这是你需要的答案。