我们的应用程序使用嵌入式Solr实例进行搜索。数据目录位于NFS上，我无法更改。 Solr的用法非常简单，有一个线程定期更新索引，并且有几个读者线程 - 这些都在一个java进程中。没有其他Solr交互发生。
使用默认的“solrconfig.xml”，我有时遇到“java.nio.channels.OverlappingFileLockException”。据我所知，原因实际上是“SimpleFSLockFactory”与NFS无法正常工作。
问题：
鉴于上述应用场景（没有并发索引修改），NoLockFactory不应该足够吗？使用NoLockFactory有什么缺点吗？如果我设置NoLockFactory，我会在错误日志中收到一些条目，说“配置警告：锁被禁用”。为什么该消息会进入错误日志？这真的被视为错误案例，为什么？
也许有比使用“NoLockFactory”更好的解决方案？
不确定这与NFS有关，但有时（很少见）我的索引被破坏了，并且在尝试更新索引时我得到了很多“java.io.FileNotFoundException：_i.fdx”。除了手动删除整个索引目录并从头开始之外，没有办法解决这个问题。为什么会发生这种情况，是否有任何优雅的方法可以自动检测损坏的索引并恢复？
答案 0 :(得分：6)
通过NFS存储索引很容易出现问题，但是如果它 要在NFS上运行，我预测这个问题可能是因为没有使用NFSv4或者没有正确使用它。 NFSv4是第一个支持锁定字节范围的版本，NFSv2＆amp; 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）是bad idea。
除了锁定问题之外，性能也可能非常糟糕。
我知道这不是你所希望的答案，但这是你需要的答案。