1

テクノロジーのバージョン:

Hibernate 3.6.5 

Hibernate Search 3.4.0 

Lucene (lucene-core-*.jar) 3.1.0

春 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>

問題:
 アプリケーションは Amazon (AWS クラウド) にデプロイされていますが、ローカル クラスターでもこの問題に直面しています。

アプリケーションの設計は、インデックス付きエンティティThreadを更新する必要があるメイン (Web) アプリケーション内から生成される があるようなものです。基本的には、.status ファイルを読み取り、30 秒ごとにデータベースを更新するステータス モニター スレッドのようなものです。これは、平均して 1 時間に約 10 分から 1/2 の間発生し続けます。問題は、Hibernate Search が問題のエンティティ (上記で説明したもの) に対して何も返さなくなるため、数日ごとにインデックスを再生成する必要があることです。

私はいくつかのフォーラムを調べましたが、Lucene インデックスを更新するスレッドは 1 つだけにするよう提案されているようです。しかし、インデックスの書き込みはスレッドセーフであるとも言えます。そのため、複数のスレッドが同じインデックスに書き込みを行っている場合でも、(検索で何も返されないという) 問題が発生しないことを期待しています。つまり、問題のエンティティのステータスが古くなる可能性がありますが、それでも何かが返されるはずです。

Hibernate Search のデフォルトの IndexReader/Writer 実装を使用しています。

どんな助けでも大歓迎です。ありがとう。

4

2 に答える 2

0

わかりました、解決策を探してここにたどり着いた人のために、これが私たちが最終的に行ったことであり、問​​題に対処しているようです (AWS でこの修正を負荷テストしましたが、これまで問題はありませんでした):

Lucene の に基づいてロック ファクトリの実装を作成しましたNativeFSLockFactory。obtainあきらめる前にロックの取得を数回再試行するようにメソッドを変更しました。待ち時間sleepを処理するために、再試行の間に短いラグ ( ) を追加しました。NFS

この修正を Lucene でテストしLockVerifyServerたところ、高負荷下では、ロック取得要求のいくつかはロックを取得するために待機する必要がありますが、最終的にはすべてのロック取得要求が対処されることがわかりました。リアルタイムで、これはインデックス ファイルの更新が成功したと解釈されます。

道を示してくれたハーディに感謝します。:)

更新:昨日、以前の値 3 でインデックス更新の遅れが発生したため、再試行回数を 30 回まで増やす必要がありました。その後は問題ないようです。

于 2012-06-07T06:27:09.397 に答える