私はこのシグナル（GOAWAY）を、Solr 以外の HTTP/2 を使っている場所でも見たことがあります。私が調べた限りでは、これはクライアント側が想定して適切に処理すべきものであり（例えば、しばらくしてから再試行するなど）、そうするのが正しいようです。

もしもっと詳しい方がいれば、ぜひ教えてください。私もただの被害者なので :)

Darioさんへ

この GOAWAY シグナルとは関係なく、私はクライアント側でドキュメントをバッファリングし、イベントごとに個別にインデックスするのではなく、まとめて処理することをお勧めします。

具体的にどの程度のバッファサイズが適切かは、ドキュメントのサイズや即時性の要件によって異なりますので、試行錯誤が必要です。私が通常最初に試すのは、200 ドキュメントのバッファサイズです。ドキュメントが非常に小さい場合はもっと多く、大きい場合はもっと少なくてもいいでしょう。

バッファがそのサイズに達したら、それらをまとめて 1 回のリクエストで Solr に送信します。ドキュメントが「遅れて」出現しては困る場合は、たとえバッファがいっぱいでなくても、例えば 1 分経過したらバッファをフラッシュする、というようにしてもよいでしょう。

Thomas

Apache Flume は、Solr シンクを通じてそのような処理（バッファリングしてまとめて送信など）を行っていましたが、少し古い技術なので、現在もサポートされているかどうかは分かりません。

こんにちは、Thomas。

私の理解では、こういった用途には ConcurrentUpdateSolrClient があると思うのですが、自分でバッファリングを実装するよりも、このクライアントを使ったほうがよいのでしょうか？

また、あなたが述べたシナリオ（200件でバッファをフラッシュし、1分以内に送信する）を実現するには、withQueueSize を 200（デフォルトは10）に設定し、solr.cloud.client.stallTime を 60000（デフォルトは15秒）に設定すればよいという理解で合ってますか？

この設定だけで本当にあなたが言ったような挙動になるかどうか、確信が持てません。

それから、バッファサイズを「バッファ内のドキュメント数」ではなく、「JavaBinCodec を使った際の実際のサイズ」で測りたい場合は、やはり自作のバッチャーを用意する必要がありますよね？

Dario

こんにちは、Dario。

私はJava開発者ではないので、JavaクライアントやJavaBinCodecの経験はありません。ただ、原理としては同じです。つまり、10件ずつ送る代わりに200件ずつまとめて送ることで、リクエスト数を95％削減できます。

もしドキュメントのサイズがほぼ同じであれば、バッファの実際のサイズ（バイト単位）を計算することにこだわる必要はないと思います。

Thomas

RFC 9113 によると、GOAWAY
https://datatracker.ietf.org/doc/html/rfc9113#name-goaway は、単にサーバーがHTTP接続を閉じたいことを意味します。
Solr自体は独自のHTTP処理コードを書いておらず、私が推測するに（あなたが使用していると述べているJDKベースのクラスを使っている）ライブラリは仕様に従っているはずなので、関連するエラーコード
https://datatracker.ietf.org/doc/html/rfc9113#NO_ERROR （NO_ERROR用のコードを含む）があります。
私はこれらのライブラリの使い方を詳細には調べていませんが、エラーコードを見ることでなぜ接続が閉じられているのかの手掛かりが得られるでしょう。
あなたの説明している状況に関連しそうなコードは以下のものです。

ENHANCE_YOUR_CALM (0x0b)：
相手側が過剰な負荷をかけている可能性のある動作を検出したことを示します。

もし私たちのクラス（HttpJdkSolrClient）がエラーコードを正しく報告していなかったり、誤って伝えたり、その他の形で不明瞭にしている場合は、その問題を修正する必要があるかもしれません。

「ドキュメントはインデックスに追加されるか？」という質問に関しては、考慮すべき点が2つあります。
仕様によると、GOAWAY は最後に処理されたストリームを指定するべきであり、それよりも大きな番号のストリームは送信されていないとみなされます。
受信済みのストリームのうち、Solrがリクエストに対して200 OKを返していれば、それはトランザクションログにアイテムが追加されたというSolr側の約束であり、インデックスにも反映されることになります。
200 OK以外のレスポンスがあればドキュメントは追加されておらず、接続が閉じる前にレスポンスが返ってこなければ確認の方法はありません。
ただし、基本的な使い方では、同じIDのドキュメントを2回送信しても安全です。これは単に削除・再追加が発生するだけだからです。
もちろん、Solrは高度にカスタマイズ可能なので、他の永続的な処理をするカスタムクラスを導入していたり、UpdateRequestProcessorsで複雑な処理をしていたり、ビジネスロジックでversionフィールドを使っている場合は影響があるかもしれません。

特別なケースがなければ、一般的な擬似コードのロジックは以下のようになります。
「もし (got200OK(request)) { 成功したインデックス処理(docs) } それ以外 { 再送スケジュール(docs) }」

よく設計されたインデックス基盤では、必要に応じて新しい接続を開始でき、Solrから200 OKのレスポンスが得られるまでインデックス用データを保持し続ける必要があります。
大量のバースト処理を受け入れる設計は、大容量のメモリが必要か、あるいは中間に永続化層やキューを設けることが多いです。
インデックスのバーストを処理できるSolrクラスタは、平均的なスループットを処理できるクラスタよりもずっと高コストになる可能性があります。
これはインデックス遅延の要件にもよります。
ビジネス的にインデックス遅延を最小化することで大きな収益が見込めるなら、全てのバーストを可能な限り早く処理できる大規模なSolrクラスタを用意する価値があります。
十分な資金があれば素晴らしいことが可能です。
私が見た例では、100ノードのクラスタが毎秒100万件以上の小さいドキュメントを受け付けていました。
これは安くはありませんでしたが、4500億件のドキュメントを1週間以内にインデックス化するために必要でした。
まずはビジネスに本当にその必要があるかどうかをよく見極めてください。

-Gus

--
http://www.needhamsoftware.com (仕事用)
https://a.co/d/b2sZLD9 (私のファンタジー小説)