Question

技术版本：

Hibernate 3.6.5

Hibernate Search 3.4.0

Lucene (lucene-core-*.jar) 3.1.0

Spring 3.1.0.M2

休眠（搜索）配置：

<prop key="hibernate.search.default.indexBase">/some/dir</prop>
<prop key="hibernate.search.default.directory_provider">org.hibernate.search.store.FSDirectoryProvider</prop>
<prop key="hibernate.search.default.locking_strategy">native</prop>
<prop key="hibernate.search.default.exclusive_index_use">false</prop>

问题：
我们的应用程序部署在亚马逊（AWS云）中，但我们也在本地集群中遇到了这个问题：

应用程序设计是从主（Web）应用程序中生成的Thread，我们需要更新 Indexed 实体。基本上它就像一个状态监视器线程，它读取.status文件并每隔30秒左右更新一次数据库。这种情况平均持续了大约10分钟到1/2个小时。我们看到的问题是：每隔几天我们就需要重新生成索引，因为Hibernate Search会停止为相关实体返回任何内容（上面讨论的那个）。

我经历了几个论坛，似乎建议只有一个线程应该更新Lucene索引。但是也给出了索引编写是线程安全的。因此，即使多个线程正在写入相同的索引，我仍然期望它不应该导致问题（搜索中没有返回任何内容）。也就是说，我可能会得到相关实体的陈旧状态，但仍然应该返回某些。

我们正在使用Hibernate Search的默认IndexReader / Writer实现。

任何帮助都将受到高度赞赏。感谢。

Answer 1

这里有一些想法。

我经历了几个论坛，似乎建议只有一个线程应该更新Lucene索引。

这通常不正确。 Lucene和Hibernate Search允许多个索引编写器， BUT 访问索引必须通过Lucene的 org.apache.lucene.store.LockFactory 正确同步。锁定工厂是可配置的，您通过属性* hibernate.search.default.locking_strategy *使用本机工具。问题可能是该策略是基于文件的。我对亚马逊的分布式文件系统内部工作情况了解不多，但我认为文件锁在这种情况下不起作用。您可能需要实现自定义锁定策略。

但是也给出了索引编写是线程安全的。所以即使有多个线程写入相同的索引，我仍然期望它不应该导致问题

正确，只要锁定有效。

另一种方法是使用w / o锁定（将* hibernate.search.default.locking_strategy *设置为 none ），前提是您可以保证只有您的更新线程才会写入索引。你有没有启用更新线程自动索引？如果是这样，请尝试转动它（允许您的用例允许）。

Answer 2

好的，对于那些寻找解决方案的人来说 - 这就是我们最终做的事情，这似乎解决了这个问题（我们已经在AWS上对此修复程序进行了负载测试，到目前为止没有问题）：

我们根据Lucene的NativeFSLockFactory编写了锁定工厂的实现。我们修改了obtain方法，以便在放弃之前重试几次锁定。我们在重试之间添加了一个短暂的延迟（sleep）来处理NFS延迟。

我们使用Lucene的LockVerifyServer测试了此修复程序，并观察到在高负载下，即使一些锁获取请求必须等待获取锁 - 但最终会解决每个锁获取请求。实时地，这解释了索引文件的成功更新。

感谢您Hardy向我们展示路径。：）

更新：昨天，我们不得不将重试次数提高到更高的数字~30，因为我们遇到的索引更新延迟与之前的值为3.事情看起来很好。

亚马逊上的Hibernate Search问题

2 个答案: