У меня есть весенняя служба подписки на сообщения из темы в Google Cloud pubsub (вытягивание). В целом работает правильно. Но я хочу иметь больший контроль над повторно отправленными сообщениями. Моей службе иногда требуется заблокировать сообщение или просто пропустить 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? Спасибо за любые предложения!
изменить: я хочу, чтобы первая повторная попытка произошла через 5 секунд, но следующая повторите попытку через 10 секунд и т. д. Плюс я хочу установить максимальное количество повторных попыток. Так что меня не интересует установка ackDeadline только на большее число.
edit2: почему nacking: одна из служб (назовем ее мостом) подписывается на сообщения, должна проверять каждое сообщение и, если все в порядке, передать его другой внешней системе. эта служба действует как мост для этой системы, поскольку мы не можем работать со второй системой напрямую. в некоторых случаях для сообщения требуется дополнительная информация, поэтому мост будет пытаться получить его где-нибудь в другом месте (включено много микросервисов), и иногда случается, что в этот момент дополнительной информации нет (пока). Итак, первая идея заключалась в том, чтобы не подтверждать сообщение и позволить ему прийти позже. но я не хочу спрашивать каждые 10 секунд в течение следующих 7 дней (с ackDeadline), я хочу просто попробовать несколько раз, и если его не будет через 2 часа, он никогда не придет. поэтому мы попытались решить эту проблему и надеялись, что эти настройки повторной попытки помогут управлять повторной отправкой. Но поскольку они этого не делают, я полагаю, что единственный выход - это создать что-то для управления этими сообщениями в мосте самостоятельно. Может быть, сохранить идентификаторы сообщений и количество повторных попыток, чтобы я мог подтвердить, например, 5 раз и отправить сообщение в другую тему, чтобы обработать его по-другому. Или известны какие-нибудь лучшие решения?
