У меня есть весенняя служба подписки на сообщения из темы в облачном пабе google (тянет).В целом работает правильно.Но я хочу иметь больше контроля над повторными сообщениями.Моему сервису иногда нужно заблокировать сообщение или просто пропустить ackDeadline, чтобы я мог получить сообщение позже.При тестировании с одиночными сообщениями, якобы полученное сообщение возвращается почти ко мне, а те, которые я вообще не проверяю или не собираю, возвращаются через 10 секунд по умолчанию для ackDeadline.Я хотел бы отложить повторное употребление этих сообщений.Я думал, что настройки повторных попыток предназначены для таких случаев.Я должен также упомянуть, что в настоящее время я тестирую локально с помощью эмулятора и создаю подписку из кода.Я использую PubSubAdmin для управления.
В соответствии с этим документом я попытался установить эту конфигурацию в конфигурации моего профиля.как это:
spring.cloud.gcp.pubsub.subscriber.retry.initial-retry-delay-second: 4
spring.cloud.gcp.pubsub.subscriber.retry.max-attempts: 5
spring.cloud.gcp.pubsub.subscriber.retry.initial-rpc-timeout-seconds: 4
spring.cloud.gcp.pubsub.subscriber.retry.max-rpc-timeout-seconds: 8
spring.cloud.gcp.pubsub.subscriber.retry.max-retry-delay-seconds: 7
spring.cloud.gcp.pubsub.subscriber.retry.total-timeout-seconds: 3000
, но это не повлияло на время повторного получения сообщений.Я неправильно понимаю значение настроек повтора?может быть, они вступают в силу только в том случае, если есть какие-то проблемы с подключением, но не в случаях с отсутствием или отсутствием подтверждения?Или мне нужно установить настройки при использовании deployManager для создания подписок, и мне не разрешено устанавливать их из кода?Или, может быть, установка их в (профилях разработки) профилей не будет работать с PubSubAdmin?Спасибо за любые предложения!
edit: я хочу, чтобы первая повторная попытка произошла через 5 секунд, но следующая повторная попытка через 10 секунд и т. Д. Плюс я хочу установить максимальное число повторных попыток.Так что меня не интересует установка ackDeadline только на большее число.
edit2: почему nacking: одна из служб (назовем ее мостом) подписывается на сообщения, должна проверять каждое сообщениеи если все в порядке, передайте его в другую внешнюю систему.этот сервис служит мостом для этой системы, так как мы не можем работать с этой второй системой напрямую.в некоторых случаях для сообщения требуется некоторая дополнительная информация, поэтому мост попытается получить его где-то еще (включая множество микросервисов), и иногда случается, что в данный момент дополнительной информации нет (пока).Таким образом, первая идея состояла в том, чтобы не подтверждать сообщение и позволить ему прийти позже.но я не хочу спрашивать каждые 10 секунд в течение следующих 7 дней (с помощью ackDeadline), я хочу просто попробовать несколько раз, и если его не будет через 2 часа, он никогда не придет.поэтому мы попытались зафиксировать и надеялись, что эти настройки повтора помогут справиться с повторной отправкой.Но так как они этого не делают, я полагаю, что единственный путь - это создать что-то для управления этими сообщениями самостоятельно.Возможно, сохраните идентификаторы сообщений и количество повторных попыток, чтобы я мог подтвердить, например, после 5 раз и переместить сообщение в другую тему, чтобы разобраться с ним по-другому.Или есть какие-нибудь лучшие решения, известные?