Gmail Javi API пакетирует слишком много запросов

Я использую Java Gmail API для получения некоторых сообщений электронной почты. Как только я получаю список сообщений, я использую пакетную обработку, чтобы получить информацию об отдельных сообщениях.

Пример кода следующим образом:

 List<MessageDto> messages = new ArrayList<>();
    String nextPageToken = null;

    List<Message> batchMessages = new ArrayList<Message>();
    ListMessagesResponse response =
            gmailClient(googleId)
                    .users()
                    .messages()
                    .list(googleId)
                    .setQ(query)
                    .setPageToken(pageToken)
                    .setMaxResults(maxResults == null ? 50 : maxResults)
                    .execute();

    if (response.getMessages() != null) {
        batchMessages.addAll(response.getMessages());
        nextPageToken = response.getNextPageToken();

        final JsonBatchCallback<Message> callback =
                new JsonBatchCallback<Message>() {
                    public void onSuccess(Message message, HttpHeaders responseHeaders) {
                        messages.add(MessageMapper.getMessage(googleId, message, false));
                    }

                    public void onFailure(GoogleJsonError e, HttpHeaders responseHeaders) {
                        log.error("Could not process message ", e);
                     
                    }
                };
        BatchRequest batch = gmailClient(googleId).batch();
           

        for (Message message : batchMessages) {
            gmailClient(googleId)
                    .users()
                    .messages()
                    .get(googleId, message.getId())
                    .setFormat("raw")
                    .queue(batch, callback);
        }
        batch.execute();
    }

Проблема, с которой я столкнулся, заключается в том, что не все пакетные сообщения извлекаются из-за слишком большого количества запросов и попадания в метод onFailure.

Я попробовал установить HttpBackOffUnsuccessfulResponseHandler на HttpRequestInitializer, но это не сработало.

Я наткнулся на это в документации: https://cloud.google.com/java/docs/reference/google-api-client/latest/com.google.api.client.googleapis.batch

Есть заметка, в которой говорится:

Примечание. При установке HttpUnsuccessfulResponseHandler путем вызова HttpRequest#setUnsuccessfulResponseHandler, обработчик вызывается каждая неудачная часть. В результате не рекомендуется использовать HttpBackOffUnsuccessfulResponseHandler для пакетного запроса, поскольку Политика отсрочки применяется для каждой неудачной части.

Есть ли способ обработать исключение слишком большого количества запросов и повторить запрос?

Любая помощь приветствуется.

Код ошибки, который вы получаете, — 429 error? Если это 429, вы можете проверить эту документацию Устраните ошибку 429: слишком много запросов . В документации также предлагается Повторить неудачные запросы для устранения ошибок

George 26.04.2024 05:07

В качестве дополнения вы также можете проверить это взаимодействие на github, в котором обсуждаются те же проблемы, что и у вас.

George 26.04.2024 05:08

@Джордж не уверен, как клиент .net поможет кому-то, использующему Java, вы не можете быть уверены, что они смогут читать Java. Это известная проблема с пакетной обработкой: вы не можете повторить неудачный запрос в пакетном запросе, чтобы сделать это, вам нужно выяснить, какие из них завершились неудачно, а какие нет, и не существует готового способа сделать это. Ошибка - это ошибка, она не говорит вам, какая именно в пакете.

Linda Lawton - DaImTo 26.04.2024 08:12
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
1
3
70
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Пакетная обработка ничего не экономит, за исключением http-вызова, который по-прежнему будет стоить столько же, сколько и ваша квота.

Когда вы отправляете пакет, скажем, из 50 запросов (это зависит от API, сколько вы можете отправить в пакете), все эти запросы попадают на сервер одновременно и выполняются. Это означает, что пакетная обработка может привести к множеству ошибок типа лавинной рассылки, которые, я думаю, вы видите. Вы не всегда будете их получать, потому что, если сервер, на который вы попадаете, занят, обработка ваших запросов может занять некоторое время. Однако, если вам удастся попасть на сервер, который не занят, все они могут запуститься в рекордно короткие сроки, и тогда вы получите сообщение об ошибке, сообщающее о вашем флуде.

Рекомендации, которые я обычно даю своим клиентам, таковы.

  1. не заморачивайтесь с пакетированием.
  2. Если вам действительно нужна пакетная обработка, держите это число на низком уровне, попробуйте 10, если вы все еще получаете ошибки, попробуйте

Если вы получаете ошибки, трудно понять, какие из них были отправлены, а какие ошибочны в пакете на некоторых API. Вам нужно будет настроить систему, чтобы проверить, было ли внесено изменение, и если нет, то отправить его в следующем пакете. Именно поэтому я рекомендую не использовать пакетную обработку.

Спасибо за понимание, Линда. По сути, я хотел уменьшить количество разговоров в сети, но не знал, что существующая квота по-прежнему будет применяться. Я также заметил, что нет простого способа определить, какие из них вышли из строя. Даже в этом случае мне придется написать специальный код, чтобы повторить их, поскольку экспонента отсрочки бесполезна. На данный момент я проведу рефакторинг кода и удалю пакетную обработку.

Swordfish 26.04.2024 14:07

Да, извини, но это к лучшему. Я сам потратил на это очень много времени.

Linda Lawton - DaImTo 26.04.2024 14:17

Другие вопросы по теме