Да, тут соглашусь, такое может быть. Это пожалуй одна из причин для чего я начал этот цикл статей - немного развеять туман в связке spring + kafka (в том числе и для себя)
События "данные обработаны" и "commit" происходят независимо друг от друга.
Почему вы так решили? В случае если мы не берём управление коммитом на себя и оставляем enable.auto.commit=true делегируя тем самым коммит KafkaConsumer последовательность вполне детерминирована :
Закоммитили предыдущий оффсет
Получили новые сообщения
Обработали
Если мы сознательно не выносим последний шаг в отдельный поток
Тут опять же все зависит от того как вы спроектируете обработку. В данном случае consumer и listener выполняются в одном потоке. Если вы отделяете обработку в отдельный поток, то и менеджмент коммитов остаётся на вашей совести. Собственно так и поступает spring-kafka при enable.auto.commit=false.
Почему не гарантируется? Все зависит от того как мы работаем с исключительными ситуациями , если используем обработчики ошибок по-умолчанию - то да, вы правы.
Тут важно отметить один момент про который я писал в первой статье: при включённой настройке enable.auto.commit=true коммит не происходит сам по себе, а жестко связан с получением сообщения.
Т.е. последовательность в цикле обработки сообщений у нас получается такая:
тут зависит от того как мы работаем с KafkaConsumer. У него есть отдельные методы commitAsync() / commitSync(), которые можно дергать руками (там есть возможность либо передать в аргуметны конкретный offset либо будет использован последний полученный при вызове poll())
Но если мы сами ничего руками не вызываем (в том числе и метод poll() для получения новых сообщений), то ничего само отправляться не будет.
Да, тут соглашусь, такое может быть. Это пожалуй одна из причин для чего я начал этот цикл статей - немного развеять туман в связке spring + kafka (в том числе и для себя)
Почему вы так решили? В случае если мы не берём управление коммитом на себя и оставляем enable.auto.commit=true делегируя тем самым коммит KafkaConsumer последовательность вполне детерминирована :
Закоммитили предыдущий оффсет
Получили новые сообщения
Обработали
Если мы сознательно не выносим последний шаг в отдельный поток
Тут опять же все зависит от того как вы спроектируете обработку. В данном случае consumer и listener выполняются в одном потоке. Если вы отделяете обработку в отдельный поток, то и менеджмент коммитов остаётся на вашей совести. Собственно так и поступает spring-kafka при enable.auto.commit=false.
Почему не гарантируется? Все зависит от того как мы работаем с исключительными ситуациями , если используем обработчики ошибок по-умолчанию - то да, вы правы.
Тут важно отметить один момент про который я писал в первой статье: при включённой настройке enable.auto.commit=true коммит не происходит сам по себе, а жестко связан с получением сообщения.
Т.е. последовательность в цикле обработки сообщений у нас получается такая:
Коммитим предыдущее смещение
Получаем новые сообщения
Обрабатываем
Но если мы сами ничего руками не вызываем (в том числе и метод poll() для получения новых сообщений), то ничего само отправляться не будет.