Comments 6
Спасибо за интересный кейс.
С почином на Хабре!)
Интересно. Можно уточнить: кто делал pausePartition,
это потребитель-приложение ваше?
Спасибо за статью, механизм @RetryableTopic интересный, для маленьких приложений находка, чтобы не создавать велосипед)
@RetryableTopic Для хайлоада будет убийцей) У нас на проекте за ночь гоняются по 7-8 млн данных и такой алгоритм ретраев может создать жесткий Кафка лаг. Мы используем ручную отправку в dlq со сдвигом офсета, либо же в отдельную таблицу и обрабатываем в мультиинстансе шедулерами(все фиксируем руками, так как нам так надежнее и мы точно знаем, что происходит)
Но опять же, если нагрузка не очень большая, то супер вообще @RetryableTopic думаю зайдет на ура, особенно, если не хочется думать над логикой ретраев)
Меня больше интересует, почему сделали значение по-умолчанию 1. На эти грабли натыкаются абсолютно все, кто использует Spring. Дошло до того, что в каждый проект добавляю интеграционный тест на проверку размера пула.
Вопрос по статье. У вас написано сколько ретраев, столько и топиков? Тут точно все в порядке с логикой?
Spring, kafka, неблокирующий retry, лаги