Слушатель Spring Kafka, использующий DeadLetterPublishingRecoverer и ручной режим подтверждения

Question

Мне трудно понять, как это можно решить, поэтому я спрашиваю об этом здесь в надежде, что кто-то другой уже столкнулся с такими же проблемами.Мы запускаем наш @KafkaListener с ручным режимом подтверждения и средством восстановления мертвых писем с пределом повторных попыток 3. Требуется ручной режим подтверждения из-за бизнес-логики, которая заключается в том, что мы не подтверждаем сообщение и делаем паузу в течение 5 минут при определенных обстоятельствах (внешние зависимости).

Также нам нужна очередь недоставленных сообщений для сообщений, которые мы не можем обработать по какой-либо причине.

Теперь проблема в ручном режиме подтверждения состоит в том, что наш слушатель / потребитель не распознаетсообщение, когда он достигает предела повторных попыток и перемещает его в очередь dl.

Если служба потребителя будет перезапущена, он попытается снова использовать сообщения и переместит их в очередь dl.

Есть идеи, как мы могли бы решить эту проблему?

Спасибо и привет из Гамбурга!

Answer 1

Я бы старался по возможности избегать ручного подтверждения;возможно, увеличив max.poll.interval.ms вместо.

Если вы используете AckMode.MANUAL_IMMEDIATE, будет безопасно выполнить фиксацию непосредственно на Consumer в обработчике ошибок.

Подкласс SeekToCurrentErrorHandler и переопределить handle(), если super.handle() не вызывает исключение, это означает, что повторные попытки превышены, и вы можете зафиксировать смещение на Consumer.