(The bot translated the original post https://lists.apache.org/thread/p3t5jbhwzy7xgyv1rlyzcqyl5d4295b5
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

こんにちは、

現在、Java 8 から Java 11 への移行を進めています。

Windows上でOpenJ9 Javaを使ってSolr 8.7.0を起動すると、次のメッセージが表示されます：

JVMJ9VM007W Command-line option unrecognised: -Xlog:gc*:file="C:\solr\server\logs\solr_gc.log":time,uptime:filecount=9,filesize=20M
JVMJ9GC063E Unable to open file '"C' for writing

その後、コンソールにはガベージコレクションの出力が続きますが、Solrは問題なく起動し、動作しているように見えます。同じリリースのJava 11 Hotspotに変更すると、警告や他の問題は見られません。

Ubuntu上のJava 11 Open J9でも同様の問題が発生します。Solrログには「Command-line option unrecognised」というメッセージが表示されますが、コンソールには表示されません。solr_gcログは正しく作成され、内容も記録されています。

これを確認したのは、OpenJDK 11.0.10+9リリースを使用した場合です。

以下は私たちの起動コマンドの例です：

C:/solr/bin/solr.cmd start -c -p 8983 -s C:/data/solr/8/clusters/is_cluster/nodes/node1 -a "-Dcom.ibm.crypto.provider.DoRSATypeChecking=false -Djetty.server=com.i2group.disco.search.solr.jetty.wrapper.XmlConfigurationWrapper -Dpkiauth.ttl=60000 -Dsolr-node-id=node1 -DzkCredentialsProvider=com.i2group.disco.search.solr.common.zookeeper.auth.internal.EncodedZkCredentialsProvider -Djdk.nativeCrypto=false" -m 2g -z "localhost:9983/is_cluster"

よろしくお願いします。

Lisa

(The bot translated the original post https://lists.apache.org/thread/4kryrpfp9bdl3dbyb77vnmlfdlcg0dcd
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

こんにちは、

現在、統合ハイライト機能でカスタムBreakIteratorを動作させる作業をしており、パフォーマンスに苦労しています。

私はパッセージの見出しをきれいにハイライトするためにBreakIteratorが必要です。これにより、ハイライトの開始が文の開始であり、終了が単語の終わりであるようにしたいです。また、いくつかの奇妙なエッジケースもあります。

すでにBreakIteratorをコーディングし、カスタムUnifiedHighlighterクラスに統合しましたが、このIteratorを使用すると、すべてのリクエストのqTimeが約1000から12000以上に上昇し、このアプリケーションでは許容できません。

こちらが私の実装へのリンクです。どこが非常に非効率的なのかを見つけることができません。（これらの関数が非常に頻繁に呼び出されることはわかっています）

他のアプローチも含め、すべての提案を歓迎します。

したがって、BreakIteratorや関連する情報について詳しく学ぶための良いリソースはありますか？ここではコードの調査が非常に難しいです。

次に検討しているもう1つのアプローチは、最終的なハイライトが見つかったときにこのハイライトの「トリミング」を行うことです。これにより、呼び出されるロジックの量が減少しますが、SOLRのスコアリングシステムが正しく考慮されない可能性があると思われます。

私が言ったように、すべての提案を歓迎し、先にお礼を申し上げます。

Jan Ulrich Robens

(The bot translated the original post https://lists.apache.org/thread/tfpn1tlgosx67n5omzpkmrdzvsbr02bd
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

こんにちは、

Solrのコントロールスクリプトを使用して新しいconfigsetをZooKeeperにアップロードしようとしたところ、-zパラメータがZK_HOST形式の文字列を認識しませんでした。

たとえば、 <ip-1>,<ip-2>,<ip-3>/solr を使用すると、configが/solr znodeではなく、直接 <ip-1> にアップロードされます。

これが意図された動作かどうかについて助けていただけないでしょうか？

注：<ip-1>/solr,<ip-2>/solr,<ip-3>/solr はうまく機能するようです。

(The bot translated the original post https://lists.apache.org/thread/vdqjcy6frv9c2kg97xh244ppj1v5jgc2
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

「Search streaming expression」で単一の特定のシャード（または特定のレプリカ）からすべてのドキュメントをストリームできますか？ 通常の「shards」パラメータを使用しても、Search streaming exprと一緒に使用すると効果がないと思います。

--ufuk

javadocによると、BeiderMorseFilterFactory はStandardTokenizerの後に使用することが推奨されています。

おそらく、GermanNormalizationFilterFactoryやGermanLightStemFilterFactoryはBeiderMorseFilterFactoryと一緒に使用すべきではありません。ステムが切り捨てられると、その発音が一致しなくなる可能性があります。

一方、異なる表記法（ß <-> ss）で書かれたドイツ語の単語を一致させたいだけなら、GermanNormalizationFilterFactoryだけで十分です。BeiderMorseFilterFactoryは必要ありません。

追伸：私はドイツ語の話者ではなく、上記の主張を実際にテストしたわけではありません。ただの推測です。