キャンセル

概要

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

言語サポート