Google.Apis.Admin.Email_Migration_v2 [HTTP状态码412



编辑2:

客户端库: 在回顾之后,很难认为这是针对。net客户端库的。

DLL: Google.Apis.Admin.email_migration_v2.dll


哪些步骤会重现问题?

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

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

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

    • 为凭据提供适当的作用域。

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

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

    • MailResource。InsertMedia对象是通过调用AdminService.Mail为每个条目生成的。插入(MailItem, string, Stream, string)方法

  3. 当我们的代码调用MailResource.InsertMediaUpload.UploadAsync(CancellationTokenSource)。结果是我们可以接收错误的地方。

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

期望的输出是什么?你看到的是什么?

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

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

    限制。[412]Errors [Message]已达到限制。位置[If-Match - header]原因[conditionNotMet]域[global]]

    在Microsoft.Runtime.CompilerServices.TaskAwaiter。ThrowForNonSuccess(工作任务)

    在Microsoft.Runtime.CompilerServices.TaskAwaiter。HandleNonSuccess(工作任务)

    1. Google.Apis.Upload.ResumableUpload"d__e.movenext ()

您使用的是哪个版本的产品?

  • Google.Apis.Admin。Email_Migration_v2 (1.8.1.20)

你的操作系统是什么?

Windows Server 2008 R2 Enterprise (SP1)你的IDE是什么?

  • Visual Studio 2013 Premium

.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:

对于任何有兴趣关注这个问题的人,这里有一个链接到谷歌的。net问题跟踪器中提交的项目。提交的问题

参考是第492期。

我不太确定你在哪里看到了" Email Migration 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错误返回。一次要加载多少数据?我建议做一个指数回退,看看这个问题是否会消失。

我相信我已经找到了这个问题的答案,尽管我建议免责声明,我不为谷歌工作,不能100%确定准确性;我警告过你了。这至少应该适用于。net版本的Google的Email Migration v2 API。我不能保证其他api是如何工作的,因为我没有使用它们。

通过使用这个API在井井式工作了八个多月,现在看来,如果一个应用程序或多个应用程序是发送消息到一个单一的谷歌应用程序用户/邮箱一致,比谷歌服务器可以处理的速度更快,那么在某种程度上,你应该开始得到一堆GoogleApiExceptions声明"412 -达到限制"发送新消息时。我们通过使用我们的应用程序收集到的是,每个Google Apps用户/邮箱都有自己的未决项队列。当您向Google Apps发送消息时,它首先被放入此队列,然后由Google服务器处理并放入用户的邮箱。如果队列已满,您尝试发送另一条消息,您将收到一个412错误。

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

当以高于每秒1个请求的速率向用户邮箱队列发送消息时,出现503个错误。正如Emily所说的"你在Google开发者控制台项目中看到的QPS限制并不是实际的默认限制",它实际上是每个Google Apps用户1个QPS。

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

这花了我们一点时间来弄清楚,所以如果你有这个问题,干杯!如果你发现任何矛盾的信息,请纠正这个答案中发现的任何错误,或者自己做!!

相关内容

  • 没有找到相关文章

最新更新