Определение BackoffStrategy для SQS в AWS - PullRequest
Новая
       44

Определение BackoffStrategy для SQS в AWS

0 голосов
/ 21 мая 2018

Я хочу настроить стратегию отката для sqs в приложении Spring.То, что я сделал: 

    @Bean
    public ConnectionFactory sqsConnectionFactory() {

        PredefinedBackoffStrategies.ExponentialBackoffStrategy backoffStrategy = new PredefinedBackoffStrategies.ExponentialBackoffStrategy(3, 27);
        RetryPolicy retryPolicy = new RetryPolicy(PredefinedRetryPolicies.DEFAULT_RETRY_CONDITION, backoffStrategy, PredefinedRetryPolicies.DEFAULT_MAX_ERROR_RETRY, false);
        return SQSConnectionFactory.builder()
                .withRegion(Region.getRegion(Regions.fromName(region)))
                .withAWSCredentialsProvider(new DefaultAWSCredentialsProviderChain())
                .withClientConfiguration(new ClientConfiguration().withRetryPolicy(retryPolicy))
                .build();
    }

, но это не имеет никакого эффекта.Я читаю из очереди SQS простым @JmsListener методом.В этом методе есть вызов к другому API.Этот API возвращает мне ошибку 404.Затем повторная попытка, но повторная попытка.Почему, как правильно настроить это с помощью экспоненциальной стратегии отсрочки?Это повторная попытка, но не с экспоненциальной задержкой.

1 Ответ

0 голосов
/ 13 ноября 2018

Стратегия отката, установленная в ClientConfiguration в вашем коде, используется для обеспечения задержки попыток клиента AWS подключиться к Сервисам AWS.Это означает, что выбранная вами стратегия будет использоваться, если (скажем, по какой-то причине) клиенту AWS SQS не удастся подключиться к сервису AWS SQS для получения сообщения (или опроса новых сообщений).Если такой сбой происходит, следующая попытка должна быть предпринята после задержки, предусмотренной сконфигурированным ExponentialBackoffStrategy.Для получения более подробной информации см. Официальную документацию здесь .

Причина немедленной повторной попытки

В вашем случае сообщение уже было получено из службы SQS базовым клиентом (то естьиспользуется Spring's @JmsListener).Неудача для этого самого шага использовала бы ExponentialBackoffStrategy.Сбой после этого (например, исключение, генерируемое после 404) вызовет подтверждение сбоя службе SQS, и служба немедленно сделает сообщение видимым для потребления снова.

Как связать стратегию отката сredelivery

К сожалению, эта стратегия не может быть связана с ошибками потребления сообщений.Задержка, которая требуется, на самом деле является спецификацией JMS 2.0 redelivery-delay .Но поставщик SQS JMS, который вы, похоже, используете, - это https://github.com/awslabs/amazon-sqs-java-messaging-lib, который является реализацией JMS 1.1.Ниже приведены те же цитаты из их документации:

Этот проект построен на основе AWS SDK для Java с использованием Amazon SQS в качестве поставщика JMS (как определено в спецификации 1.1)

Кроме того, SQS не имеет ничего похожего на redelivery-delay в своей политике переадресации (только ассоциация Maximum Receives и Dead Letter Queue).Таким образом, возможный обходной путь будет заключаться в том, чтобы самостоятельно обрабатывать сбои и устанавливать определенные задержки сообщений (больше здесь ) постепенно для каждой повторной очереди (это может включать обработку числа повторов в заголовках, вероятно, и не использовать JMS).).Обратите внимание, что это может повлечь дополнительные расходы.

С другой стороны: Добавление задержки в очередь или таймаута видимости не поможет в задержках между сбоями при чтении сообщений.

...