1

最近HibernateSearch4.1にアップグレードしましたが、ロックに関して休止状態で行われた変更に基づいてJUnitテストを実行するとエラーが発生します。AbstractTransactionalJUnit4SpringContextTestsを使用してJUnitテストを実行すると、各テストの後にロックが残っていることがよくあります。（ Hibernate-Searchインデックスリカバリの処理方法）のレビューで、ネイティブロックを試しましたが、これで問題が解決しませんでした。

デフォルトのディレクトリプロバイダー（Filestore）を使用して、さまざまなロックメカニズム（シンプル、シングル、ネイティブ）を試し、次のようなメッセージを定期的に確認しました。

build   20-Apr-2012 07:07:53    ERROR 2012-04-20 07:07:53,290 154053 (LogErrorHandler.java:83) org.hibernate.search.exception.impl.LogErrorHandler  - HSEARCH000058: HSEARCH000117: IOException on the IndexWriter
build   20-Apr-2012 07:07:53    org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@target/indexes/Resource/write.lock
build   20-Apr-2012 07:07:53        at org.apache.lucene.store.Lock.obtain(Lock.java:84)
build   20-Apr-2012 07:07:53        at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1108)

また

build   19-Apr-2012 19:31:09    ERROR 2012-04-19 19:31:09,395 153552 (LuceneBackendTaskStreamer.java:61) org.hibernate.search.backend.impl.lucene.LuceneBackendTaskStreamer  - HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!

これらのメッセージの一部は、あるテストから別のテストにカスケードするロックの問題を示しているようです。したがって、リセットが必要です。また、テストが「無効な」動作とアプリケーションの反応をテストしているため、有効な場合もありますが、多くの場合、 IDがnullであるこのような場合

build   19-Apr-2012 19:31:11    Primary Failure:
build   19-Apr-2012 19:31:11        Entity org.tdar.core.bean.resource.CodingSheet  Id null  Work Type  org.hibernate.search.backend.PurgeAllLuceneWork

ただし、それでも、あるテストが別のテストに影響を与えないようにする必要があります。

いくつかの議論（ディレクトリプロバイダーに関する電子メールの議論）を読んで、RAMベースのディレクトリプロバイダーがより良いオプションであるかもしれないと提案されましたが、可能な限り本番環境で使用するのと同じプロバイダーを使用することをお勧めします。

テストの合間にHibernateSearchをリセットして、ロックファイルをクリーンアップし、インデックスが同期していないか破損している潜在的な問題をリセットするにはどうすればよいですか？テストスイートの開始時に、インデックスディレクトリをワイプしますが、テストのたびにワイプすることをお勧めしますか？

ありがとう

4

2 に答える 2

2

ディレクトリに古いロックがある場合、Hibernate Search が確実にロックを閉じるので、Hibernate Search が適切にシャットダウンされなかったことを意味します。

各テストで新しい Hibernate SessionFactory を開始する場合は、テストの実行後に閉じていることも確認する必要があります。

org.hibernate.SessionFactory.close()

(Hibernate SessionFactory を閉じるのを忘れても目立った問題はないため、これは多くの例で欠落していることがよくありますが、オプションではなく、接続やスレッドがリークする可能性があります)。

リンク先の Hibernate メーリング リストのスレッドは、Hibernate Search 4.1 でネイティブ ハンドルを使用するようにロックを変更することになりました。これにより、JVM がクラッシュまたは強制終了された場合にロックが自動的にクリーンアップされます。しかし、あなたの場合、テスト間で VM を強制終了していないと思うので、サービスをシャットダウンしてロックが適切に解放されていることを確認する必要があります。

Exclusive_index_use=falseは、IndexWriter が各トランザクションの終了時に閉じられるため、問題を隠します。ただし、IndexWriter を再利用する方がはるかに効率的であるため、速度は遅くなります。Hibernate Search 4.1 へのアップグレード後にこの問題が発生する理由は、このオプションがデフォルトでtrueに変更されたためです。ただし、それでも適切に閉じる必要があります。

于 2012-04-25T19:47:40.820 に答える