Посмотрел ReplyingKafkaTemplate - он работает только если correlation_id (в нашем случае request_id) которые лежат в хидере. У нас же этот request_id лежит в боди сообщения. И если при отправки сообщения в нем в принципе легко поменять CorrelationIdStrategy, то на листенере это сделать уже проблематично.
С вашими словами не поспоришь, и в них есть доля правды. Если бы была возможность интеграции по ресту - то и статьи не было бы. Но я почему то уверен что такое бывает не только у нас, возможно кому то пригодится решение или хотя бы часть его. Но решать надо было быстро. К слову на текущий момент рест интеграция уже готова, после окончания тестирования мы конечно же быстренько и с легкостью освободим свой гараж от лишеного велосипеда. Не хотите поделиться как бы вы поступили в такой ситуации??
Спасибо за комментарий и за то, что обратили внимание на этот аспект! Действительно, использование кеширующих структур с автоудалением — отличное решение. Интересно было бы узнать ваше мнение о том, какой из предложенных подходов вы считаете наиболее удобным в реализации и почему? Поделитесь опытом или идеями, это было очень полезно!
Спасибо вам за настойчивость в решениях. Безусловно решение с распределенным кешом выглядит заманчиво и просто.
В статье описан один из вариантов, который нам показался наиболее простым в реализации и достаточно эффективным в отведенные сроки.
Проблему оффсетов для себя рассматривали как минимальную или если сказать по простому как вы и написали - забили.
Учитывая что вся проверка происходит в момент запроса от клиента - если произойдет STW или отвалится консьюмер - у клиента высветится окошко по типу 'попробуйте позже', после чего он спокойно еще раз сможет попробовать, где на вторую попытку подключения вероятность подобной проблемы уже крайне мала.
Редис и Хазел внутри нашего приложения не используются - любая новая интеграция кажется более сложным решением по сравнением со встроенными механизмами джава. Новая интеграция это сетевые задержки, это точка которую надо поддерживать, мониторить... - в общем на первый взгляд не кажется простым решением.
я так понимаю продолжение следует...
Посмотрел ReplyingKafkaTemplate - он работает только если correlation_id (в нашем случае request_id) которые лежат в хидере. У нас же этот request_id лежит в боди сообщения. И если при отправки сообщения в нем в принципе легко поменять CorrelationIdStrategy, то на листенере это сделать уже проблематично.
Спасибо за ReplyingKafkaTemplate. От меня лайк за совет!
С вашими словами не поспоришь, и в них есть доля правды. Если бы была возможность интеграции по ресту - то и статьи не было бы. Но я почему то уверен что такое бывает не только у нас, возможно кому то пригодится решение или хотя бы часть его. Но решать надо было быстро. К слову на текущий момент рест интеграция уже готова, после окончания тестирования мы конечно же быстренько и с легкостью освободим свой гараж от лишеного велосипеда. Не хотите поделиться как бы вы поступили в такой ситуации??
Спасибо за комментарий и за то, что обратили внимание на этот аспект! Действительно, использование кеширующих структур с автоудалением — отличное решение. Интересно было бы узнать ваше мнение о том, какой из предложенных подходов вы считаете наиболее удобным в реализации и почему? Поделитесь опытом или идеями, это было очень полезно!
Спасибо вам за настойчивость в решениях. Безусловно решение с распределенным кешом выглядит заманчиво и просто.
В статье описан один из вариантов, который нам показался наиболее простым в реализации и достаточно эффективным в отведенные сроки.
Проблему оффсетов для себя рассматривали как минимальную или если сказать по простому как вы и написали - забили.
Учитывая что вся проверка происходит в момент запроса от клиента - если произойдет STW или отвалится консьюмер - у клиента высветится окошко по типу 'попробуйте позже', после чего он спокойно еще раз сможет попробовать, где на вторую попытку подключения вероятность подобной проблемы уже крайне мала.
Редис и Хазел внутри нашего приложения не используются - любая новая интеграция кажется более сложным решением по сравнением со встроенными механизмами джава. Новая интеграция это сетевые задержки, это точка которую надо поддерживать, мониторить... - в общем на первый взгляд не кажется простым решением.