2017-12-19 15 views
0

solrサーバーバージョン6.6とsolrj 6.6を使用しています。org.apache.lucene.store.AlreadyClosedException:このIndexWriterが閉じている

現在のところ、solrコアはglusterfsマウントパーティション上に作成されます。 マウントされたボリューム上にsolrコア用の十分なスペースがあります。 また、一部のコアではこの問題は見られませんが、他のコアでは一貫したエラーがあり、以下に述べる例外がスローされます。

例外チェーン: org.apache.solr.common.SolrException:例外書き込み文書ID WI:インデックスへ5-1-8。可能な分析エラー。

どのようなアイデアや回避策もありがたいです。 :)

+0

例外スタックトレースでは、次も参照してください:原因:org.apache.lucene.store.AlreadyClosedException:2017-12-18T16:33:01.144935Zで外部の力で元のファイルが変更されました(lock = NativeFSLock (path =/data_de_de/data/index/write.lock、impl = sun.nio.ch.FileLockImpl [0:9223372036854775807排他的有効]、creationTime = 2017-12-18T16:33:02.057688Z)) –

答えて

0

アクセスモードのglusterfsタイプの永続的なボリュームRWX(Read Write Many)を主張するために使用されるkubernetsに展開されたSOLRサーバーポッド。ストレージ クラスの新しいperistentのボリュームとボリュームの主張を作成した後

:噴石(デフォルトオープンスタックのブロックストレージ)とRWOに設定されたアクセス モード付き(ライトワンスリード)とのSolrサーバ ポッドのためにそれを使用してSolrExceptionを取り除くことができました。

lucene(solr)のように見えるのは、差分ポッド用に読み書き権限が割り当てられたglusterfsパーティションではうまくいきません。新しいファイルの変更を同期するのに多くの時間がかかるように見えるので、luceneは必要なときにロックを取ることができず、すぐに多くの外部の力がsolrコアのwrite.lockファイルをロックしようとしていると言いました。だからあなたのsolrコアのための共有gluster fsの分割を使用しないでください。

関連する問題