/solr/admin/cores ハンドラーは、他の /solr/admin で始まるハンドラーと同様に、グローバル ハンドラーです。これらのハンドラーは、特定のコアを指定せずに全体の Solr インスタンスに対して操作を行うことができます。カスタムのグローバルハンドラーを作成したい場合は、ImplicitPlugins.json に定義を追加することができますが、このファイルは solr-core jar に埋め込まれています。jar の操作を行う必要がない場合は、ソースコードを変更して Solr を再コンパイルするのが最良です。ハンドラーの jar を server/lib/ext に追加することもできますが、一部の場合（あなたの場合がそれに当てはまるかどうかはわかりませんが）、その jar を webapp の WEB-INF/lib に追加する必要があります。

多くのハンドラーは各コアに固有であり、そのため /solr/CORENAME で始まり、指定されたコアに対してのみ操作を行います。admin という名前のコアを作成しないでください。それはグローバルハンドラーと干渉する可能性があります。

また、Solr を ZooKeeper と共にクラウドモードで実行している場合、/solr/admin/cores をコアの再読み込み以外の目的で使用するべきではありません。実際の変更は /solr/admin/collections を使用して行う必要があります。それ以外の場合、クラスターを混乱させるリスクがあります。再読み込みもコレクションハンドラーを使用することが推奨されています。

ありがとう、
Shawn

こちらの例 https://issues.apache.org/jira/browse/SOLR-15859 をご覧ください。ここでは、新しいグローバルハンドラーを作成しています。

ImplicitPlugins.json を server/lib/ext のような場所に配置することで、Solr を再コンパイルするか jar の操作を行う必要がないかもしれません。server/lib/ext は、WEB-INF よりも前にクラスパスで検索されると思います。さらに良い方法として、ユーザーが指定した暗黙のハンドラーを定義できる別の json ファイルを用意することが考えられます。

ありがとうございます。
Shawn

Shawn、ありがとう。提案してくれた内容は非常に役立つと思います。Solrのノードレベルで作業を行いたいケースが確かにありますね。フィールドキャッシュもその一例です。

私の場合、特定のノード上のすべてのコアがロードされ、クエリ可能であることを確認するシンプルなヘルスチェックリクエストハンドラを作成しようとしています。Pingリクエストハンドラはコアレベルで動作しますが、solrの再起動後でも他のコアがまだロード中の場合でも、/solr/admin/cores APIは私にとって機能しますが、OKステータスで返されます。

追記：私はレガシーセットアップ（非クラウド）を使用しています。

9.xでは、カスタムの非検索クエリに応答する別のサーブレットを書くことが可能になるはずです。その場合、編集する必要があるのはweb.xmlだけです。org.apache.solr.servlet.CoreContainerProvider#getCoreContainerを通じてコアコンテナにアクセスできます。

コードを見る限り、そのメソッドがパブリックではないため、まだapacheパッケージ内に存在する必要がありますが、それに対する実証可能なユースケースがあれば、将来のバージョンでパブリックにすることができると思います。それがパブリックに調整されれば、暗黙のプラグインの変更を回避でき、adminの下に置く必要もなく、/server/solr-webapp/webapp/WEB-INF/libに別のjarを挿入して読み込むことが可能になるでしょう。

選択する際に考慮すべき質問は、エンドポイントを認証で保護するかどうかです。もしそうなら、ショーンの方法で行う必要があります。もしインフラシステムなどへの公開（ログイン不要）が必要な場合は、サーブレットの方がより便利かもしれません。それはすべてのセキュリティ設定の外に存在するためです。

以下は、コアコンテナレベルのプラグインの例です：
https://github.com/yasa-org/yasa/tree/master/yasa-solr-plugin

https://issues.apache.org/jira/browse/SOLR-14404

ありがとう、Ishan。これはSolr 8.6以上でのみ利用可能ですか？私は8.5.0を使っています :(

それから、これはSolrCloudモードでのみサポートされていますか？

そうです。
ここを見てください：
https://solr.apache.org/guide/solr/latest/configuration-guide/cluster-plugins.html

Jan

これを解決できたら、あなたが行ったことを書き留めてくれると素晴らしいですね。ブログは将来プラグインを作成する人々にとって素晴らしいリソースになるでしょう。

よろしくお願いします。
Charlie

残念ながら、私はまだレガシーモードで、クラウドモードではありません。
そのため、この機能を活用することはできません :(

一方で、Solrプラグインを実装し、期待通りに動作していますが、唯一の問題は、あるコアのコンテキストで呼び出す必要があることです。
数字でコアを参照することができるかどうか疑問に思っています。例えば、/solr/0/my/api/call のように、/solr//my/api/call の代わりにコアを番号で参照できるかどうか。こうすることで、特定のコアの名前を知らなくてもノードレベルの情報を取得できるので、少なくとも問題は軽減されるでしょう。

リストに再送します。誤ってエンドユーザーにだけ送信してしまいました。二度も！

現在、グローバルハンドラ（例えば /admin/collections や /admin/cores など）は CoreContainer クラスのコードで追加されています。

開発者のみなさんに考慮していただきたいアイデアがあります： ImplicitPlugins.json に似たファイルで、例えば NodeImplicitPlugins.json や CoreContainerImplicitPlugins.json という名前のファイルを、ImplicitPlugins.json と同じ solr-core jar ファイル内に配置しませんか？そして、両方のコードパスでクラスパス上の User* という名前のファイルを探すようにします。その後、ユーザーは ${solr.solr.home}/lib に UserImplicitPlugins.json や UserNodeImplicitPlugins.json をユーザーが提供するjarファイルと一緒に追加するだけで、それらのハンドラが自動的に利用可能になります。

これは、コアを番号で指定するアイデアが間違っていると言う意味ではありませんが... もしあなたのプラグインがノードやクラスタ向けであれば、コアやコレクションレベルでアクセスする必要はありません。そのため、コア番号の必要もありません。上記のアイデアのようなものが追加されるまでの間、solrconfig.xml にハンドラを持つ特定の名前の空のコアを各ノードに作成し、そのコア名を使用してハンドラにアクセスすることができます。

よろしくお願いします。
Shawn

Shawn、ありがとう。このヘルスチェックのためだけに完全なコアを作成することには少し懸念があります。
コアを作成することは、キャッシュや登録される他の多くの要素を考慮すると、ややコストがかかるのではないでしょうか？もしそれで問題がなければ、その解決策で進めてもいいかもしれません。

私が言っているのは、全くクエリを送信しない完全に空のコアのことです。もしそれにクエリが送信されなければ、キャッシュのために重要なメモリは必要ありません。

以下は、必要なものだけで新しいコアを作成するために使用した最小限の設定とスキーマです。キャッシュの定義がないため、Solrのキャッシュは作成されません。おそらくLuceneのキャッシュはいくつか作成されるかもしれませんが、それらは空のため非常に小さなものになるでしょう。この定義では、クエリを送信することはできないと思います。

solrconfig.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<config>
  <luceneMatchVersion>LATEST</luceneMatchVersion>
  <requestHandler name="/your/handler/path" class="YOURCLASSNAME">
    *** YOUR HANDLER に必要なすべての設定 ***
  </requestHandler>
</config>

managed-schema.xml:

<?xml version="1.0" encoding="UTF-8"?>
<schema name="empty" version="1.6">
  <fieldType name="string" class="solr.StrField" omitNorms="true"
sortMissingLast="true" docValues="true"/>
  <fieldType name="long" class="solr.LongPointField"
positionIncrementGap="0" docValues="true"/>
  <field name="id" type="string" indexed="true" required="true"
stored="true"/>
  <field name="_version_" type="long" indexed="false" stored="false"/>
  <uniqueKey>id</uniqueKey>
</schema>

この設定では、コアのメモリフットプリントが絶対的に最小限になるはずです。おそらく数メガバイト程度です。そして、将来的にSolrのあるバージョンで全てのコアのメモリフットプリントを減らすための取り組みが進められていると思います。理論的には、このコアのメモリ要件をさらに小さくすることができるでしょう。

将来的には、ユーザーがグローバルハンドラを登録し、このような空のコアを不要にする方法を提供できることを願っています。

ありがとうございます、
Shawn

Shawn、ありがとうございます。とても役立ちます。この解決策を使います！