2

編集2:

クライアント ライブラリ:確認したところ、これが .NET クライアント ライブラリ用であるとは簡単には言えません。

DLL: Google.Apis.Admin.email_migration_v2.dll


問題を再現する手順は何ですか?

  1. メッセージが送信される一意の Google Apps Gmail メールボックスごとに、Google.Apis.Admin.email_migration_v2.AdminService インスタンスを含むプロセスを生成します。生成されたすべての AdminService オブジェクトは、同じ OAuth2.0 資格情報とアプリケーション名を使用します。生成された各 AdminService オブジェクトは、1 人の Google Apps ユーザーのメールボックスにのみメッセージを送信します。たとえば、5 つの異なる Google Apps Gmail メールボックスにメッセージを送信する場合、メッセージを送信するために 5 つの AdminService オブジェクトを生成します。各ユーザーのメールボックスに 1 つ。

    • 最も注意すべき点は、作成される各 AdminService オブジェクトが個別のプロセスで作成されることです。

    • AdminService オブジェクトには、リフレッシュ トークンが保存される場所を変更するための FileDataStore オブジェクトが与えられました。C:\ProgramData\SomeFile\SomeFile.

    • 資格情報に適切なスコープを提供しました。

  2. 各プロセスでメール メッセージの送信を開始します。各プロセスで 1 つのスレッドを使用してメッセージを送信するため、一度に 1 つのメッセージのみが各ユーザーのメールボックスに送信されます。

    • 送信された各メッセージは、MailItem と MailResource.InsetMedia の独自のインスタンスを取得します。

    • MailResource.InsertMedia オブジェクトは、AdminService.Mail.Insert(MailItem, string, Stream, string) メソッドを呼び出すことによって、アイテムごとに生成されます。

  3. コードが MailResource.InsertMediaUpload.UploadAsync(CancellationTokenSource).Result を呼び出すと、エラーを受け取ることができます。

    • エラーは、前述の呼び出しの戻り値の型からキャッチされ、処理 (ログに記録) されます。タイプは Google.Apis.Upload.IUploadProgress です。例外は、IUploadProgress.Exception プロパティを使用して処理されます。

期待される出力は何ですか?代わりに何が見えますか?

  • 予想される出力は、成功メッセージの応答、またはタスクのリターン後に IUploadProgress の例外プロパティが null になることです。代わりに、次のエラー メッセージが表示されます。

    サービス管理者が例外をスローしました: Google.GoogleApiException:Google.Api.Requests.RequestError

    限界に達しました。[412] エラー [メッセージ[制限に達しました。] 場所[If-Match - ヘッダー] 理由[条件が満たされていない] ドメイン[グローバル]]

    Microsoft.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (タスク タスク) で

    Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess (タスク タスク) で

    Google.Api.Upload.ResumableUpload`1.d__e.MoveNext() で

使用している製品のバージョンは何ですか?

  • Google.Apis.Admin.Email_Migration_v2 (1.8.1.20)

お使いのオペレーティング システムは何ですか?

  • Windows Server 2008 R2 エンタープライズ (SP1)

あなたのIDEは何ですか?

  • Visual Studio 2013 プレミアム

.NET フレームワークのバージョンは?

  • 4.0.30319

以下の追加情報を提供してください。

  • 連続していないメッセージは、メッセージの送信プロセス中に (上記の 412 http ステータス コードで) 失敗する可能性があります。このエラーを受け取ると、失敗したメッセージの後に送信された他のメッセージは成功する可能性があります。(アイテムは、プロセスの開始、中間、または終了のどの時点でも失敗する可能性があります。)

  • 送信される各メッセージの内容はほぼ同じです。メッセージのサイズは、関連するすべての添付ファイルのサイズを含めて 1KB から 100KB の範囲であり、すべてのメッセージに添付ファイルがあるわけではありません。

  • 失敗したアイテムを後で再処理すると、メッセージの応答が成功し、適切なアイテムがユーザーの Google Apps Gmail 受信トレイに送信されます。

  • 一度に送信される Google Apps ユーザーのメールボックスの最大数は 10 でした。

  • Google Developers Console プロジェクトのクォータを確認した後:

    • Email Migration API で指定された 1 秒あたり 20 リクエストの制限にはほど遠いものでした。1 秒間に 7 回のリクエストを送信することで最大になりました。

    • 1 日の最大リクエスト数の 2% にしか達していませんでした。

  • 送信されたすべてのメッセージには同じラベルが付いていました。ラベルは 225 文字の制限を大幅に下回っていました。実際には、一緒に適用されたすべてのラベル/サブラベルは 40 文字に過ぎませんでした。

  • このエラー メッセージは、1 人の Google Apps ユーザーのメールボックスにのみ送信した場合でも受信されることがあります。1 つのプロセスと 1 つのスレッドのみを使用します。

  • 通常、各プロセスは 1000 ~ 5000 のメッセージを送信しています。

  • この特定のエラーを詳細に説明して、目前の問題を解決するための特定のドキュメントはあまり見つかりませんでした。

質問:

  1. では、この 412 http ステータス コードは正確には何を意味するのでしょうか? このメッセージが参照している制限は何ですか?
  2. 制限に達している場合、サーバーから何らかの形式の 5XX エラーを受け取るべきではありませんか? どのような場合に、組み込みの指数バックオフ ポリシーが適用されないのでしょうか?
    • を。サーバーがサーバー側の制限に関する前提条件について POST 要求をチェックしていない限り、412 エラーが通常示しているように、クライアントにバックオフするように指示します。その場合、質問 1 についてできるだけ詳しく説明してください。

長文投稿失礼します!御時間ありがとうございます!また、Google の .NET イシュー トラッカーで欠陥/問題を作成し、リンクを提供します。


編集1:

この問題を追跡することに関心のある方は、Google の .NET 用イシュー トラッカーに送信された項目へのリンクを以下に示します。 提出された問題

参考までに492号です。

4

2 に答える 2

0

この問題に対する答えを見つけたと思いますが、免責事項をお知らせしますが、私は Google で働いていないため、その正確性を 100% 確信することはできません。あなたは警告されました。これは、少なくとも Google の Email Migration v2 API の .NET バージョンには当てはまるはずです。私はそれらを使用していないので、他の API の動作を保証することはできません..

この API を 8 か月以上にわたって使用してきた結果、1 つまたは複数のアプリケーションが 1 つの Google Apps ユーザー/メールボックスに一貫してメッセージを送信する場合、Google サーバーが処理できるよりも速い速度で、新しいメッセージを送信するときに、「412 - Limit Reached」を示す一連の GoogleApiExceptions を取得し始める必要があります。アプリケーションを使用して収集したことは、各 Google Apps ユーザー/メールボックスに独自の保留中のアイテム キューがあることです。メッセージを Google Apps に送信すると、まずこのキューに入れられてから、Google サーバーによって処理され、ユーザーのメールボックスに入れられます。このキューがいっぱいになり、別のメッセージを送信しようとすると、412 エラーが返されます。

オプションは、別のメッセージを送信する前に待機することです。別のメッセージを送信する前に、Google サーバーがユーザーのキュー内の次のメッセージを処理するのにかかる時間を待つ必要があります。これは予測不可能です。私の意見では、より良いオプションは、別の Google Apps ユーザーにメッセージを送信することです。各ユーザーは独自のメッセージ キューを持っているように見えるためです。常に 412 エラーが発生しているユーザーへの送信を停止してください。これにより、Google サーバーがそのユーザーのパックされたメッセージ キューを処理するための時間が与えられます。保留中の各メッセージ キューは、412 エラーをスローする前に、約 100 ~ 150 個のアイテムを保持しているように見えることに注意してください。

503 エラーは、ユーザーのメールボックス キューに 1 秒あたり 1 リクエストを超える速度でメッセージを送信すると発生するようです。Emily が「Google Developers Console プロジェクトに表示される QPS 制限は、実際のデフォルトの制限ではありません」と述べているように、実際には Google Apps ユーザーあたり 1 QPS です。

指数バックオフについては、自動的に実装されるはずですthisを参照してください。注 Peleyal は API を担当する紳士のようです。API のダウンロード ページから確認できます。

これを理解するのに少し時間がかかりました。この問題が発生している場合は、乾杯してください! 矛盾する情報を見つけた場合は、この回答で見つかった間違いを修正するか、自分で作成してください!!

于 2015-03-11T21:14:29.567 に答える
0

「Email Migration API に対して 1 秒あたり 20 リクエストという指定された制限」がどこに表示されているのかよくわかりません。注意: Google Developers Console プロジェクトに表示される QPS 制限は、実際のデフォルトの制限ではありません。この制限は任意に変更できます。したがって、それは API の実際の制限ではありません。これは実際には、API クォータの消費を管理するためだけのものです (一部の API は QPS がはるかに高く、コンソール全体のさまざまなプロジェクトで QPS を低く調整できます)。

メール移行 API のドキュメントによると、QPS は 1 秒あたり 1 リクエストです (リンクはこちら: https://developers.google.com/admin-sdk/email-migration/v2/limits )。

QPS 制限に達したときに 412 エラーが発生したことがあります。また、1 つのドメインに大量のデータをアップロードしているときに 412 エラーが返されることもありました。一度にロードするデータ量はどれくらいですか? 問題が解消されるかどうかを確認するために、指数バックオフを実行することをお勧めします。

于 2014-09-29T21:51:05.880 に答える