【问题标题】:Google.Apis.Admin.Email_Migration_v2 [HTTP Status Code 412 – Limit Reached]Google.Apis.Admin.Email_Migration_v2 [HTTP 状态代码 412 - 已达到限制]
【发布时间】:2014-09-29 19:41:47
【问题描述】:

编辑 2:

客户端库:经过审查,不容易认为这是针对 .NET 客户端库的。

DLL: Google.Apis.Admin.email_migration_v2.dll


哪些步骤会重现问题?

  1. 生成一个包含 每个 Google.Apis.Admin.email_migration_v2.AdminService 实例 将向其发送邮件的唯一 Google Apps Gmail 邮箱。 生成的所有 AdminService 对象都使用相同的 OAuth2.0 凭据和应用程序名称。生成的每个 AdminService 对象 只会将消息发送到一个 Google Apps 用户的邮箱。为了 例如,如果我们向五个不同的 Google Apps 发送消息 我们将生成五个 AdminService 对象来发送的 Gmail 邮箱 消息;每个用户的邮箱一个。

    • 最需要注意的是,创建的每个 AdminService 对象都是在单独的进程上创建的。

    • AdminService 对象被赋予一个 FileDataStore 对象来更改刷新令牌的存储位置; C:\ProgramData\SomeFile\SomeFile.

    • 为凭据提供了适当的范围。

  2. 开始在每个进程上发送邮件消息。每个进程使用一个线程发送消息,因此每次只发送一条消息到每个用户的邮箱。

    • 发送的每条消息都有自己的 MailItem 和 MailResource.InsetMedia 实例

    • 通过调用 AdminService.Mail.Insert(MailItem, string, Stream, string) 方法为每个项目生成 MailResource.InsertMedia 对象。

  3. 当我们的代码调用 MailResource.InsertMediaUpload.UploadAsync(CancellationTokenSource).Result 时,我们会收到错误消息。

    • 从上述调用的返回类型中捕获并处理(记录)错误;类型是 Google.Apis.Upload.IUploadProgress。使用 IUploadProgress.Exception 属性处理异常。

预期的输出是什么?你看到了什么?

  • 预期的输出将是成功的消息响应或任务返回后 IUploadProgress 的异常属性为空。相反,我们收到以下错误消息:

    服务管理员抛出异常: Google.GoogleApiException:Google.Apis.Requests.RequestError

    已达到限制。 [412] 错误 [消息[达到限制。] 位置[If-Match - 标头] 原因[conditionNotMet] 域[全局]]

    在 Microsoft.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(任务任务)

    在 Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(任务任务)

    在 Google.Apis.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 用户的邮箱最多发送到一个 时间是十点。

  • 检查我们的 Google Developers Console 项目的配额后:

    • 对于每秒 20 个请求的指定限制,我们还差得很远 电子邮件迁移 API;每秒最多发送 7 个请求。

    • 仅达到每日最大请求的 2%。

  • 所有发送的消息都有相同的标签;标签正好在 225 个字符限制。实际上应用了所有标签/子标签 加起来只超过 40 个字符。

  • 仅发送到一个时仍会收到此错误消息 Google Apps 用户的邮箱;只使用一个进程和一个线程。

  • 每个进程通常发送 1000-5000 条消息。

  • 我没有找到很多具体的文档来足够详细地解释这个特定的错误来解决手头的问题。

问题:

  1. 那么这个 412 http 状态码到底是什么意思呢?此消息所指的限制是什么?
  2. 如果我们达到限制,我们是否应该从服务器收到某种形式的 5XX 错误?在这种情况下,内置的指数回退策略不会启动吗?
    • 一个。除非服务器正在检查 POST 请求以获取有关服务器端限制的先决条件,否则会告诉客户端后退,这似乎是 412 错误通常表明的内容。在这种情况下,请尽可能详细地说明问题 1。

抱歉,这篇文章太长了!谢谢你的时间!我还将在 Google 的 .NET 问题跟踪器中创建一个缺陷/问题并提供一个链接。


编辑 1:

对于有兴趣关注此问题的任何人,此处是指向 Google 的 .NET 问题跟踪器中已提交项目的链接。 Submitted Issue

供参考,这是第 492 期。

【问题讨论】:

    标签: c# .net google-api google-api-dotnet-client google-email-migration


    【解决方案1】:

    我不太确定您在哪里看到“电子邮件迁移 API 每秒 20 个请求的指定限制”。提醒:您在 Google Developers Console 项目中看到的 QPS 限制并不是实际的默认限制。您可以将该限制更改为您想要的任何内容,因此,这不是 API 的实际限制。它实际上只是用于管理 API 配额的消耗(某些 API 将具有更高的 QPS,您可以在控制台中针对不同项目将其调整为更低)。

    根据电子邮件迁移 APi 文档,QPS 是每秒 1 个请求(链接在这里:https://developers.google.com/admin-sdk/email-migration/v2/limits)。

    我在达到 QPS 限制时遇到了 412 错误,当我将太多数据上传到单个域时,我也看到返回 412 错误。您一次要加载多少数据?我建议做一个指数退避,看看问题是否会消失。

    【讨论】:

    • 我在上一个线程中被告知,API 的 .NET 客户端库会自动实现指数回退策略。
    • 这里是上一篇文章/线程的链接Link 注意:似乎是与维护API相关的绅士。对于请求,同时向十个不同的邮箱发送消息,每个邮箱都有一个单独的进程,每个进程只使用一个线程;试图避免每个邮箱的 1QPS 问题。 IE。每个邮箱一次发送一封邮件,但是我们仍然一次发送到十个不同的邮箱。因此,一个进程必须以比 1QPS 更快的速度发送消息。
    • 现在,如果其中一个进程打破了每个邮箱 1QPS 的限制,那么我的印象是会返回一些基于 5XX 服务器的错误。因此,默认的指数回退策略将启动。至于多少数据,邮件平均大约 10KB(加上附件),使用十个邮箱,每个邮箱大约 500-2000 封邮件,因此大致为 48MB-195MB。我已经浏览了我能找到的所有文档,我很可能只是误解了一些明显的东西。顺便说一句,感谢您的时间和支持 =]
    【解决方案2】:

    我相信我已经找到了这个问题的答案,虽然我会提出免责声明,但我不为 Google 工作,并且不能 100% 确定其准确性;你已经被警告过了。这至少应该适用于 .NET 版本的 Google 电子邮件迁移 v2 API。我不能保证其他 API 是如何工作的,因为我不使用它们..

    通过使用此 API 八个月以上的时间,如果一个应用程序或多个应用程序要始终如一地向单个 Google Apps 用户/邮箱发送消息,似乎比 Google 服务器可以处理的速度更快,那么在发送新消息时,您应该以某种速度开始收到一堆 GoogleApiExceptions 声明“412 - 已达到限制”。我们通过使用我们的应用程序收集到的是每个 Google Apps 用户/邮箱都有自己的待处理项目队列。当您向 Google Apps 发送消息时,它首先被放入此队列,然后由 Google 服务器处理并放入用户的邮箱。如果此队列已满并且您尝试发送另一条消息,您将收到 412 错误。

    选项是在发送另一条消息之前等待,您必须等待 Google 服务器在发送另一条消息之前处理用户队列中的下一条消息所需的时间;这是不可预测的。我认为更好的选择是开始向另一个 Google Apps 用户发送消息;因为每个用户似乎都有自己的消息队列。请务必停止发送给不断收到 412 错误的用户。这将给 Google 服务器一些时间来处理该用户的打包消息队列。请注意,在抛出 412 错误之前,每个待处理消息队列似乎都包含大约 100-150 个项目。

    以高于每秒 1 个请求的速率将邮件发送到用户的邮箱队列时,似乎会发生 503 错误。正如 Emily 所说,“您在 Google Developers Console 项目中看到的 QPS 限制并不是实际的默认限制”,它确实是每个 Google Apps 用户 1 QPS。

    至于指数回退,它应该是自动实现的,请参阅this。注意 Peleyal 似乎是负责 API 的绅士;可以从 API 的下载页面注意到。

    我们花了一点时间才弄明白,如果您遇到这个问题,那就欢呼吧!如果您发现任何相互矛盾的信息,请更正此答案中发现的任何错误或自己制作!

    【讨论】:

    • 对于任何未来的读者来说,这似乎只是现在已弃用的“电子邮件迁移 v2 API”的问题。这不是 Gmail API 的问题。 Gmail API 在允许客户端发送下一条邮件消息之前等待消息完全被服务器端摄取。这个功能甚至被谷歌记录了,找不到链接。
    猜你喜欢
    • 2012-05-30
    • 2017-01-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-01-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多