jvmchat | Unsorted

Telegram-канал jvmchat - pro.jvm

5916

Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез

Subscribe to a channel

pro.jvm

Когда создается тред и выполняет какую-либо работу (платформенный или виртуальный - без разницы), то каким образом расходуется память?

Читать полностью…

pro.jvm

Так если будет пул с нескольки платформенных, которые на консьюмера будут выделять по одному виртуальному
Не будет ли это выгоднее ?

Читать полностью…

pro.jvm

Приходит 1000 сообщений которые нужно куда то отправить и забить
Зачем на каждый выделять по платформ треду?

Читать полностью…

pro.jvm

А как идея использовать виртуальные треды для Кафка консьюмеров флоу которых в конце-концов упираются в IO вызов ?
Что бы избавиться от лишнего мемори оверхеда

Читать полностью…

pro.jvm

Вот я бы вообще не стал такого делать

Читать полностью…

pro.jvm

Тогда рассуждения выше как минимум не совсем актуальны

Читать полностью…

pro.jvm

да он в отпуске, как вернется, я ему напишу об этом, а пока сделал, как написал выше.

за рассуждения тож спасиб)

Читать полностью…

pro.jvm

Так это в рамках группы вроде

Читать полностью…

pro.jvm

Мне кажется это плохое решение

Читать полностью…

pro.jvm

Я вопрос по этому посту задал. /channel/jvmchat/623442

Читать полностью…

pro.jvm

Ну тип как ключ -- это просто раскидывать в разные партишены. А группу то как на партишен ассайнить? Вручную? Что то меня в этой схеме смущает всё.

Читать полностью…

pro.jvm

можно указать тип как ключ. но это такое, лучше таки на разные топики поделить

Читать полностью…

pro.jvm

привет

тот кейс, который ты описал с партициями и группами - рабочий 100%, но вот привязываться к определенными партициям в перспективе масштабирования, наверное, не круто (усложняет логику как минимум, на мой взгляд), поэтому я его сразу отмел. По поводу отдельного топика - самый простой и идеальный вариант, но, к сожалению, на разбиение на два топика лично я не могу повлиять (архитектуру описывал не я).

https://github.com/spring-cloud/spring-cloud-stream-samples/tree/main/routing-samples я про вот такой роутинг. Думал, мб кто-то такое делал, хотя выглядит, как костылец, конечно)

Ну и с каждым днем убеждаюсь, что простых вариантов только два и те описаны тобой в сообщении.

Сделаю две группы для одного топика, в одном и втором консюмере буду скипать неподходящее сообщение, определяя их по признаку из хедеров.

пасиба за ответ и свой опыт)

Читать полностью…

pro.jvm

ансейф - это как "эффект", любая функция может быть помечена как ансейф, её можно вызывать только в ансейф блоке

Читать полностью…

pro.jvm

Рэбиту чтобы гарантии соблюсти нужно fsync делать на диск. Кафке нет, так как несколько брокеров с репликацией(за счёт этого высокие гарантии). Это не говоря о других нюансах.

Читать полностью…

pro.jvm

На сообщение которое упадёт в консьюмера*

Читать полностью…

pro.jvm

Так памяти не будет меньше расходоваться

Читать полностью…

pro.jvm

где виртуальные треды избавляют от мемори оверхеда?

Читать полностью…

pro.jvm

А сам сервак запускает виртуальный поток на http запрос для обработки этого запроса?

Читать полностью…

pro.jvm

Получается можно тупо автокоммитить оффсет даже если сообщение не то, всё-равно он свой на каждую КГ насколько помню)

Читать полностью…

pro.jvm

Похоже что да, спасибо, сначала не обратил внимания.

Читать полностью…

pro.jvm

Ага, я тоже подумал вчера что мануал ак выставить и либо по заголовкам, либо по результату парсинга скипать чтобы другая группа пришла и прочитала.
Но вероятно, чтобы минимизировать скипы нужно будет подумать про стратегию раутинга и ассайна консьюмеров.
В идеале чтобы в партишнах каждой КГ было примерно поровну А и Б сообщений. И не получилось что КГ на А будет читать партишны куда преимущественно Б сыплются.

Ещё в порядке бреда настроить раутинг чтоб в половину партишнов А, в половину Б шли(по ключу например) и подгадать чтобы А КГ на А партишны ассайнился тем же RangeAssignor, а Б на Б.
Но выглядит что мало вероятно что стабильно работать будет, а если и будет, то легко сломать, и при ребалансах ХЗ как себя поведёт.

А, вообще, интересно почему с т.з. архитектуры решили писать в один топик разные виды сообщений. Наверняка не глупый человек дизайнил.

Читать полностью…

pro.jvm

Существуют разные стратегии https://chrzaszcz.dev/2021/09/kafka-assignors/, дефолтая вроде как RangeAssignor. Но можно настаивать через вот эту пропертю https://kafka.apache.org/documentation/#consumerconfigs_partition.assignment.strategy

Читать полностью…

pro.jvm

Там явно написано что разные группы на разные партиции ассайнятся

Читать полностью…

pro.jvm

а зачем разные группы?

Читать полностью…

pro.jvm

а нужен именно он? обычная интеграция с кафкой не подойдет?

Читать полностью…

pro.jvm

кафка не умеет, spring-cloud-stream умеет (хотя я уже не уверен, так как сэмпл из сообщения выше не завелся на последних версиях 😃), либо я не так понял, как это дело работает

Читать полностью…

pro.jvm

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

Читать полностью…

pro.jvm

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

Читать полностью…

pro.jvm

А ансейф код знают только системные программисты-сениоры?

Читать полностью…
Subscribe to a channel