tools.jar можно тянуть зависимостью с мавена

Здравствуйте, существует три микросервиса (A, B, C)
Сервис А - выступает в роли источника информации "а"
Сервис Б - берет пачками информацию с сервиса А, и конвертирует их в вид "б"
Сервису C нужно получить всю информацию сервиса А, в конвертиророваном виде через сервис Б.
Вопрос какие рекомендации, использование каких технологий поможет мне гарантировано(в случае ошибки, повторно запросить пачку) получить все "пачки". Думаю распараллелить запросы, на эти пачки для ускорения времени обработки тоже отличная идея но нужно гарантировать что они точно будут получены
Объем последовательной обработки информации занимаем достаточно много времени, по этому я желаю распараллелить запросы на получения с сервиса Б

Я думал использовать брокер сообщений, будто это разрешит мне безопасно ускорить процес

а не проще сервис А научить выдавать всё так как надо сервису С ?
чтоб не городить очередь сообщений, придумывать какие-то обходные пути и тд

звучит как типичная задача для систем класса ESB. источники, потребители, между ними - очереди и трансформация

можно попробовать построить какое-то решение поверх кафки (для возможности перечитывания сообщений), можно взять что-то готовое

стало лень искать, нашёл в чём беда?
а то я собираюсь на днях повышать с 2.3.5 на 2.4.2)

да, нашел. коротко - нельзя вешать @Bean над методом, у которого внутри используется applicationContext.getBean.
обсуждение:
https://github.com/spring-projects/spring-framework/issues/26369

спасибо👍

можешь попробовать сначала смигрироваться на 2.3.7. если не заметишь деградации, значит, конкретно эта проблема не стрельнула.

да не, по идее у меня вообще нет прототайпов да и бинов в таком кол-ве, так что должно всё гладко пройти
предварительно миграция на 2.4.1 на локали прошла гладко)

это я для инфы поинтересовался, вдруг пригодится когда-нибудь

дергать applicationContext.getBean в принципе не очень хорошо

тем более в конфигурации

обычно да. но у меня сложная логика выбора, бины каких типов нужно инстанцировать. обвешиваться тоннами кондишеналами - только размазывать эту логику и терять производительность. эта "конфигурация" по сути является обжект провайдером и просто отвечает за инстанцирование бина нужного типа. выбор типа же находится в другом месте.

Всем привет!
Какие есть подходы для тестирования, когда в теле тестируемого метода вызываются публичные методы, которые принимают в качестве параметра функции, в которых есть некоторое количество логики?
Вопрос в том как протестировать эту логику.
Пока вижу два варианта -
1. Вынести эту логику в публичный метод какого-то сервиса и тестить ее отдельно.
2. Использовать  ArgumentCaptor<ExampleSomeConsumer<SomeClass>> и после уже получать из него переданную функцию и тестировать ее. Но этот вариант "попахивает", на мой взгляд

Привет! Тестируйте абстракции отдельно

вопрос возникнет скорее когда логики очень немного, условно пара if-else.
Выносить такое в отдельную абстракцию не кажется оптимальным решением

Чтобы не гадать, можете примерный код накидать?

Не подскажите, а для кликхауса же есть проверенный реактивный клиент (webflux)?