2

Edit 2:Google.Apis.Admin.Email_Migration_v2 [HTTP код состояния 412 - Предел Достигнута]

Client Library: После рассмотрения его не так легко предположить, что это для клиентской библиотеки .NET ,

DLL: Google.Apis.Admin.email_migration_v2.dll


Какие шаги воспроизвести проблему?

  1. Сформировать процесс, который содержит Google.Apis.Admin.email_migration_v2.AdminService экземпляр для каждого уникального почтового ящика Gmail в Google Apps, которые будут иметь сообщения, отправленные на него. Все созданные объекты AdminService используют те же OAuth2.0 учетные данные и имя приложения. Каждый объект AdminService, созданный , будет отправлять сообщения только одному почтовому ящику пользователя Google Apps. Например, при отправке сообщений в пять разных почтовых ящиков Gmail Google Apps Gmail мы будем генерировать пять объектов AdminService для отправки сообщений ; один для каждого почтового ящика пользователя.

    • Самое важное, что каждый созданный объект AdminService создается отдельным процессом.

    • Объектам AdminService был предоставлен объект FileDataStore, чтобы изменить местоположение места хранения токена обновления; C: \ ProgramData \ некий-файл \ некий-файл.

    • Поставляется с соответствующими полномочиями на учетные данные.

  2. Начать отправку почтовых сообщений на каждый процесс. Использование одного потока для отправки сообщений в каждом процессе, поэтому только одно сообщение отправляется за раз в почтовый ящик каждого пользователя.

    • Каждое сообщение, отправленное получает свой собственный экземпляр MailItem и MailResource.InsetMedia

    • Объект MailResource.InsertMedia генерируется для каждого элемента с помощью вызова AdminService.Mail.Insert (MailItem, строка, поток, строка).

  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 (Task задача)

    на Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess (задача Task)

    в Google.Apis.Upload.ResumableUpload`1.d__e.MoveNext()

Какую версию продукта вы с помощью?

  • Google.Apis.Admin.Email_Migration_v2 (1.8.1.20)

Что такое операционная система?

  • Windows Server 2008 R2 Enterprise (SP1)

Что такое ваш IDE?

  • Visual Studio 2013 Премиум

Что является основой .NET версии?

  • 4.0.30319

Просьба представить любую дополнительную информацию ниже.

  • непоследовательных сообщения может не (с кодом состояния 412 HTTP Приведенную выше) во время процесса отправки сообщений. Как только мы получим эту ошибку другие сообщения, отправленные после неудачного сообщения (ов) может преуспеть. (Элементы могут терпеть неудачу в любой момент во время процесса Начало, Середина или конец.)

  • Каждое отправленное сообщение имеет почти идентичный контент.Размер сообщений варьируется от 1 КБ до 100 КБ, включая размер всех связанных вложений, не все сообщения имеют вложения.

  • Повторный обработка неисправных деталей на более позднее время приводит успешные ответы сообщений и соответствующие пункты направляются пользователь Служб Google Gmail Входящие.

  • Максимальное количество почтовых ящиков пользователей Google Apps, отправленных на один , составляло десять.

  • После проверки квоты нашего проекта Google Developers Console:

    • Мы не были далеки от указанного предела 20 запросов в секунду для API переноса электронной почты; maxed при отправке 7 запросов в секунду.

    • Только 2% от максимальной ежедневной заявки было достигнуто.

  • Все сообщения, отправленные с такой же меткой; ярлык был под лимитом 225 символов. Фактически все наклейки/суб-метки, нанесенные , вместе взяты только до 40 символов.

  • Это сообщение об ошибке может быть получено при отправке только одному почтовому ящику пользователя Google Apps; используя только один процесс и один поток.

  • Каждый процесс обычно отправляет от 1000 до 5000 сообщений.

  • Я не нашел много конкретной документации, чтобы объяснить эту конкретную ошибку достаточно подробно, чтобы исправить эту проблему.

Вопросы:

  1. Так что же делает это 412 HTTP код состояния? Какое ограничение встречается в этом сообщении?
  2. Разве мы не должны получать некоторую форму ошибки 5XX с сервера, если мы нажимаем лимит? В таком случае не будет выстроена встроенная экспоненциальная политика?
    • a. Если сервер не проверяет POST-запрос на предварительное условие о пределе на стороне сервера, а затем говорит клиенту о необходимости отступить, что, как правило, указывает на ошибку 412. В этом случае, пожалуйста, дайте максимально подробно, насколько это возможно для вопроса 1.

Извините за обширной пост! Спасибо за ваше время! Я также создаю дефект/проблему в трекере Google для отслеживания ошибок .NET и предоставил ссылку.


Edit 1:

Для тех, кто заинтересован в следующих этот вопрос здесь является ссылка на представленный элемент в системе отслеживания проблем Google для .NET. Submitted Issue

Для справки это вопрос 492.

ответ

0

Я считаю, что я нашел ответ на эту проблему, хотя я советую отказаться от ответственности, я не работаю в Google и не могу быть на 100% уверен в точности; вы были предупреждены. Это должно, по крайней мере, соответствовать версии .NET API электронной почты M2 v2 API. Я не могу гарантировать, как работают другие API, потому что я их не использую.

. Работая с этим API в течение более чем восьми месяцев, кажется, что если приложение или несколько приложений отправляют сообщения в один Google Пользователь/почтовый ящик приложений последовательно, с более быстрыми темпами, чем серверы Google могут обрабатывать, то в некоторой степени вы должны начать получать кучу GoogleApiExceptions, указав «412 - Limit Reached» при отправке новых сообщений. Что мы собрали с помощью нашего приложения, так это то, что каждый пользователь/почтовый ящик Google Apps имеет свою собственную очередь ожидающих элементов. Когда вы отправляете сообщение в Google Apps, он сначала помещается в эту очередь, прежде чем обрабатывается сервером Google и помещается в почтовый ящик пользователя. Если эта очередь заполняется и вы пытаетесь отправить другое сообщение, вы получите ошибку 412.

Параметры должны ждать перед отправкой другого сообщения, вам придется ждать, сколько времени сервер Google предпримет, чтобы обработать следующее сообщение в очереди пользователя перед отправкой другого; что непредсказуемо. Лучший вариант, на мой взгляд, - начать отправку сообщений другому пользователю Google Apps; потому что каждый пользователь имеет свою собственную очередь сообщений. Обязательно прекратите отправку пользователю, который последовательно получает 412 ошибок. Это даст серверу Google некоторое время для обработки очереди упакованных сообщений пользователя. Обратите внимание, что в каждой очереди ожидающих сообщений хранилось около 100-150 элементов, прежде чем выбрасывать 412 ошибок.

При отправке сообщений в очередь почтовых ящиков пользователя происходит более 503 ошибок с более высокой скоростью, чем 1 запрос в секунду. Как Эмили заявила: «Ограничение QPS, которое вы видите в проекте Google Developers Console, не является фактическим лимитом по умолчанию», это действительно 1 QPS на пользователя Google Apps.

Что касается экспоненциального отступления, предполагается, что он будет автоматически реализован в this. Примечание. Пелей является, по-видимому, джентльменом, отвечающим за API; можно отметить со страницы загрузки для API.

Это заняло у нас немного времени, чтобы разобраться в таких урах, если у вас есть эта проблема! Если вы обнаружите какую-либо противоречащую информацию, исправьте ошибки, обнаруженные в этом ответе, или сделайте свой собственный!

+0

Для любых будущих читателей это, похоже, только проблема с устаревшим «API миграции электронной почты v2». Это не проблема с API Gmail. API Gmail ожидает, что сообщения будут полностью проглочены на стороне сервера, прежде чем разрешить клиенту отправлять следующее почтовое сообщение. Эта функциональность даже документирована Google, не может найти ссылку. – 580

0

Я не совсем уверен, где вы видите «указанный предел 20 запросов в секунду для API переноса электронной почты». Напоминание: предел QPS, который вы видите в проекте Google Developers Console, не является фактическим лимитом по умолчанию. Вы можете изменить этот предел на все, что хотите, и, следовательно, это не фактический предел для API. Это действительно просто для управления потреблением квоты API (некоторые APis будут иметь гораздо более высокий QPS, где вы можете настроить его для снижения для разных проектов на своей консоли).

Согласно документации APi по миграции электронной почты, QPS составляет 1 запрос в секунду (ссылка находится здесь: https://developers.google.com/admin-sdk/email-migration/v2/limits).

У меня было 412 ошибок при ударе предела QPS, и я также видел ошибку 412, возвращенную, когда я загружаю слишком много данных в один домен. Сколько данных вы загружаете сразу? Я бы предложил сделать экспоненциальную отсрочку, чтобы увидеть, исчезнет ли проблема.

+0

Мне сообщили в предыдущем потоке, что клиентская библиотека .NET для API автоматически реализует экспоненциальную политику возврата. – 580

+0

Вот ссылка на предыдущее сообщение/нить [Ссылка] (http://stackoverflow.com/questions/20435181/google-apis-email-migration-v2) Примечание: Появляется джентльмен, связанный с поддержкой API. Что касается запросов, отправляющих сообщения в десять разных почтовых ящиков одновременно, для каждого почтового ящика буферизируется отдельный процесс, в котором каждый процесс использует только один поток; чтобы попытаться избежать 1QPS для каждой проблемы с почтовым ящиком. И.Е. Одно почтовое сообщение на каждый отправленный почтовый ящик, однако мы по-прежнему отправляем сразу десять разных почтовых ящиков. Таким образом, один процесс должен отправлять сообщения быстрее, чем 1QPS. – 580

+0

Теперь, если один из процессов нарушил этот 1QPS на лимит почтового ящика, когда я находился под впечатлением, что будет возвращена ошибка на основе сервера 5XX. Таким образом, будет проведена стандартная экспоненциальная политика отбрасывания. Что касается количества данных, составляющих в среднем около 10 КБ (плюс вложения), используется десять почтовых ящиков с примерно 500-2000 почтовыми сообщениями, поэтому примерно 48 МБ-195 МБ. Я прошел через каждую документацию, которую я могу найти, я вполне могу просто неверно истолковать что-то очевидное. Btw, спасибо за ваше время и поддержку =] – 580

Смежные вопросы