jvmchat | Unsorted

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

5916

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

Subscribe to a channel

pro.jvm

просто интересно, могут ли консьюмеры в rabbitmq только нужные сообщения брать? что кафка не умеет. ну например какое-нибудь правило задать в самом rabbitmq, что из stream, только нужные сообщения отдаются. не на уровне консьюмера, а на уровне rabbitmq.

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

pro.jvm

именно streams часть у rabbitmq

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

pro.jvm

Расскажите, пожалуйста, как разные группы на разные партишены ассайнятся? Очень интересно стало.

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

pro.jvm

Смотрел в сторону того как раутятся А и Б сообщения по партишнам, там точно всё в порядке? Про консьюмеры хз как они могут читать только конкретные типы сообщений, сталкивался только что разные группы на разные партишны ассайнятся(соответственно при такой логике нужно чтобы и А и Б типы строго в определённые партишны шли и ассайн консьюмеров был соответственный), но каким образом выбор происходит тоже не копал.

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

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

pro.jvm

да не, от меня такое ожидать опрометчиво

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

pro.jvm

Чет сломался. Little's law ничего не говорит про пиковую производительность, т.е. здесь буквально считают прибыль от 1rps и 1mrps одинаково.

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

pro.jvm

Немного разбавлю дискус про потоки снова кафкой и таким кейсом: есть один топик, на него подписано два консюмера, первый консюмер обрабатывает сообщения типа А, второй - типа В; после десериализации сообщения типа А попадают в первый консюмер, сообщения типа Б попадают также в первый консюмер и сыпется исключение СlassCastException.

Не могу понять, почему роутинг работает не верно :( Если кто-то сталкивался, буду благодарен помощи.

В моем случае используется spring boot 3.2.0, spring-cloud-stream-bindings 4.1.0.

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

pro.jvm

Создавать миллион потоков бесконтрольно, когда мы не выигрываем в выделенной памяти, такое себе преимущество, как по мне. Всё-равно сервак свалится с ООМ, еще и пулом не ограничить, как с платформенными. Держать в виртуальном потоке только ту страницу стек фрейма, что нужна для обработки - в этом же и был смысл. Тогда можно и миллион тредов создавать.

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

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

pro.jvm

Речь же о памяти в стеке? В вирт потоках аллокация памяти динамическая и изначально значительно ниже. По сути постраничный стек фрейминг, остальная часть оптимизированная в хипе. Если я правильно понял вопрос

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

pro.jvm

Нет, это всё мои виртуальные сущности и аккаунты в интернете. Сейчас напишу с них всех:

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

pro.jvm

Полез в первую попавшуюся статью, обожаю такое. Прямо рядом указывается реальный res, при чем тестируют там (естественно) вызовы никакущей вложенности, потому и стек ничего не жрёт.

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

pro.jvm

Ему для реального выделения этого мегабайта надо весь стек пройти и аллоцировать страницы, нет?

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

pro.jvm

На сихнроназейд секциях не будет саспендиться и платформенный поток вместе с виртуальным

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

pro.jvm

Поэтому в сентябре 2025 всем надо переходить на JDK25

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

pro.jvm

В последней джаве порешают synchronised. Нативные вызовы нет. Хотя наверно это и так все знают

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

pro.jvm

Не сталкивался со стримами в реббите, но думаю зависит от. Если вам нужны хорошие механизмы маршрутизации, то я бы смотрел на кролика. Иначе Кафка.

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

pro.jvm

а вообще kafka по производительности лучше чем rabbitmq?

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

pro.jvm

Какой роутинг? Кафка - тупая труба. У нее философия dumb pipes smart clients. Нет у Кафки никакого роутинга. Если констюмер подписался на топик, то он читает из него всё. В вашем примере констюмер а и б каждый потребит все сообщения. И это часть их логики выкинуть сообщения, которые им не нужны.

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

pro.jvm

This reduces W by a factor of three, but the interaction with the remote services also adds three more sub-operations in-flight, increasing our level of concurrency, L, also by a factor of three, and the two cancel out.


Я еле понял, что он на самом деле имеет в виду лямбду, а не L.
Только он отталкивается от arrival rate как от количества запросов, а не внутренних операций, для которых W-то от параллелизации никак не меняется.

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

pro.jvm

Я боюсь я не осилю дискуссию с объяснениями уровня Шипилёва. Разрешите слиться

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

pro.jvm

Блин, это старье, но что в закладках осталось: https://inside.java/2020/08/07/loom-performance/

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

pro.jvm

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

еще и пулом не ограничить, как с платформенными.

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

Не понимаю выигрыша. Стек так или иначе разматывается обратно ровно так же, как и наполняется.

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

pro.jvm

Да

В вирт потоках аллокация памяти динамическая и изначально значительно ниже.

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

и
часть оптимизированная

- это не пон

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

pro.jvm

На ютуб канале жавы есть разбор

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

pro.jvm

Написано же VIRT — это виртуальные треды сожрали 14.3G! /s

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

pro.jvm

И мне прямо очень сложно поверить в один килобайт стека на сервлете со всеми цепочками doNext doNext service dao proxy pooled delegate

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

pro.jvm

Сейчас решение этого: выкидывать синхронайзед и заменять его на juc locks, например, ReentrantLock

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

pro.jvm

да я найду, перечитаю
просто подзабыл

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

pro.jvm

Не хочу голословным быть, там их тест хитрее был

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

pro.jvm

у нетфликс вроде все в syncronized уперлось, насколько помню ?

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