キャンセル

概要

gRPCクライアントは、RPC呼び出しの結果に興味がなくなった場合、サーバーにその関心の終了を通知するためにキャンセルすることができます。デッドラインの期限切れやI/Oエラーもキャンセルのトリガーとなります。RPCがキャンセルされると、サーバーは進行中の計算を停止し、ストリームのサーバー側を終了する必要があります。多くの場合、サーバーはアップストリームサーバーのクライアントでもあるため、キャンセル操作は、元のクライアントRPC呼び出しによって開始されたシステム内のすべての進行中の計算に、理想的には伝播されるべきです。

クライアントがRPCをキャンセルする理由はいくつかあります。要求したデータが不要になったか、クライアントの作成者がサーバーの良き市民として計算リソースを節約したい場合があります。

sequenceDiagram
  Client ->> Server 1: Cancel
  Server 1 ->> Server 2: Cancel

クライアント側でのRPC呼び出しのキャンセル

クライアントは、呼び出しオブジェクトのメソッド、または一部の言語では付随するコンテキストオブジェクトのメソッドを呼び出すことによってRPC呼び出しをキャンセルします。gRPCクライアントはサーバーにキャンセルの理由に関する追加情報を提供しませんが、キャンセルAPI呼び出しは理由を記述する文字列を受け付け、これによりクライアント側の例外や/または提供された理由を含むログが生成されます。サーバーがRPCのキャンセルを通知されたとき、アプリケーション提供のサーバーハンドラはリクエストの処理に忙しい場合があります。gRPCライブラリには、一般的にアプリケーション提供のサーバーハンドラを中断するメカニズムがないため、サーバーハンドラはローカルでのリクエスト処理が停止することを保証するために、gRPCライブラリと連携する必要があります。したがって、RPCが長期間続く場合、そのサーバーハンドラは、サービス中のRPCがキャンセルされたかどうかを定期的にチェックし、キャンセルされている場合は処理を停止する必要があります。一部の言語は、送信中のRPCの自動キャンセルもサポートしますが、それ以外の場合は、サーバーハンドラ作成者の責任となります。

flowchart LR
  subgraph Client
  end
  subgraph Server1
    direction TB
    cancelled{cancelled?} -->|false| perform("perform some work")
    perform --> cancelled
    cancelled -->|true| cleanup("cancel upstream RPCs")
    cleanup --> exit("exit RPC handler")
  end
  subgraph Server2
  end

  Client -->|CANCEL| Server1
  Server1 -->|CANCEL| Server2

言語サポート