тогда все просто - как и советовали выше миниму х2, х3 если есть вероятность потратить время на чтото другое

Привет, можно ли в spring webflux в контроллере отдающим не-Flux/Mono ответ отключить заголовок Transfer-Encoding: chunked ?

нашел только вариант устанавливать content-length, но это как-то не очень, вычислять длину ответа вручную для сериализуемых данных.

Спасибо! Учту))

жыза...

Всем привет! Есть задача, в которой нужно слушать порядка 15-20 топиков кафки, у сообщений из каждого топика достаточно похожая логика обработки, но есть и свои особенности. Есть ли смысл собирать все эти кафкаЛистенеры в один сервис, только ради того, чтобы меньше дублировать код и держать все в одном месте? И если их разбивать на несколько сервисов, то каким кол-вом кафкаЛистенеров на сервис лучше ограничиться?

Ну нужно смотреть, насколько разделима/объединима эта логика, и в чём именно выражается похожесть.
Если действительно единственный критерий общности — "есть похожие куски кода", объединять это в один сервис я бы не стал, скорее подумал бы над тем, чтобы самые "шаблонные" из этих вещей повыносить в какой-нибудь там commons-модуль/библиотеку, и, условно, заменить 30 строк одинакового кода на 3-5 вызовов одних и тех методов с разными параметрами. Если же у листенеров и логически что-то общее прослеживается, скорее даже с точки зрения домена - может и объединить.

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

Не будет ли удара по перформансу с таким кол-вом листенеров? Там же на каждый партишн свой тред получается.

Я б сказал, тут надо и учиться корректировать свои оценки - это полезный скилл - и смотреть, насколько эти оценки действительно критичны. Классический совет: поговорите с руководителем, спросите "а так ли нужны эти оценки" - может, и правда нужны, по крайней мере, в текущей модели работы и планирования, чтобы, например, прикидывать, что будут делать другие люди и команды. А может и не нужно.

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

Вот тут часто ставят под сомнение.
Но спрос всегда за выполнение в срок. Перешел к умножению срока на два, но тоже не всегда помогает - такое часто режется, да и задачи бывают из серии сделать новую фичу в незнакомом сервисе, который еще в глаза не видел. Как оценить такие задачи вообще не понятно

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

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

Ты в оцрв оффер принял?

нет

тогда включай писанину, распиши что увидел, почему это будет стоить дорого,
так чтобы до руководства донести
писанина всегда помогает, так как в случае чего, её можно третьей стороне показать

хорошая идея )

Ну по листенеру на топик. А по логике - выделите класс с общей логикой и отнаследуйте от него слушателей

чужие сервисы всегда будут, тут только способность быстро выъезжать в код и быстро разбираться с чем-то новым поможет