просто интересно, могут ли консьюмеры в rabbitmq только нужные сообщения брать? что кафка не умеет. ну например какое-нибудь правило задать в самом rabbitmq, что из stream, только нужные сообщения отдаются. не на уровне консьюмера, а на уровне rabbitmq.
Читать полностью…Расскажите, пожалуйста, как разные группы на разные партишены ассайнятся? Очень интересно стало.
Читать полностью…Смотрел в сторону того как раутятся А и Б сообщения по партишнам, там точно всё в порядке? Про консьюмеры хз как они могут читать только конкретные типы сообщений, сталкивался только что разные группы на разные партишны ассайнятся(соответственно при такой логике нужно чтобы и А и Б типы строго в определённые партишны шли и ассайн консьюмеров был соответственный), но каким образом выбор происходит тоже не копал.
А, вообще, я в подобной ситуации просто разные топики делал, меньше гемора.
Чет сломался. Little's law ничего не говорит про пиковую производительность, т.е. здесь буквально считают прибыль от 1rps и 1mrps одинаково.
Читать полностью…Немного разбавлю дискус про потоки снова кафкой и таким кейсом: есть один топик, на него подписано два консюмера, первый консюмер обрабатывает сообщения типа А, второй - типа В; после десериализации сообщения типа А попадают в первый консюмер, сообщения типа Б попадают также в первый консюмер и сыпется исключение СlassCastException.
Не могу понять, почему роутинг работает не верно :( Если кто-то сталкивался, буду благодарен помощи.
В моем случае используется spring boot 3.2.0, spring-cloud-stream-bindings 4.1.0.
Создавать миллион потоков бесконтрольно, когда мы не выигрываем в выделенной памяти, такое себе преимущество, как по мне. Всё-равно сервак свалится с ООМ, еще и пулом не ограничить, как с платформенными. Держать в виртуальном потоке только ту страницу стек фрейма, что нужна для обработки - в этом же и был смысл. Тогда можно и миллион тредов создавать.
По поводу тормозов - если не ошибаюсь, ребята из Loom рассказывали, что проигрыш в этом моменте преимуществами параллелизации. Как и переключением контекста потоков в целом. Там даже формула приводилась
Речь же о памяти в стеке? В вирт потоках аллокация памяти динамическая и изначально значительно ниже. По сути постраничный стек фрейминг, остальная часть оптимизированная в хипе. Если я правильно понял вопрос
Читать полностью…Нет, это всё мои виртуальные сущности и аккаунты в интернете. Сейчас напишу с них всех:
Читать полностью…Полез в первую попавшуюся статью, обожаю такое. Прямо рядом указывается реальный res, при чем тестируют там (естественно) вызовы никакущей вложенности, потому и стек ничего не жрёт.
Читать полностью…Ему для реального выделения этого мегабайта надо весь стек пройти и аллоцировать страницы, нет?
Читать полностью…На сихнроназейд секциях не будет саспендиться и платформенный поток вместе с виртуальным
Читать полностью…В последней джаве порешают synchronised. Нативные вызовы нет. Хотя наверно это и так все знают
Читать полностью…Не сталкивался со стримами в реббите, но думаю зависит от. Если вам нужны хорошие механизмы маршрутизации, то я бы смотрел на кролика. Иначе Кафка.
Читать полностью…Какой роутинг? Кафка - тупая труба. У нее философия dumb pipes smart clients. Нет у Кафки никакого роутинга. Если констюмер подписался на топик, то он читает из него всё. В вашем примере констюмер а и б каждый потребит все сообщения. И это часть их логики выкинуть сообщения, которые им не нужны.
Читать полностью…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.
Блин, это старье, но что в закладках осталось: https://inside.java/2020/08/07/loom-performance/
Читать полностью…Его не обязательно создавать одномоментно. Вопрос в дорогих вызовах к операционке и контекст свитчах. Но пулы лучше по-прежнему держать под рукой.
еще и пулом не ограничить, как с платформенными.
Держать в виртуальном потоке только ту страницу стек фрейма, что нужна для обработки - в этом же и был смысл.
Да
В вирт потоках аллокация памяти динамическая и изначально значительно ниже.
постраничный стек фрейминг
часть оптимизированная
И мне прямо очень сложно поверить в один килобайт стека на сервлете со всеми цепочками doNext doNext service dao proxy pooled delegate
Читать полностью…Сейчас решение этого: выкидывать синхронайзед и заменять его на juc locks, например, ReentrantLock
Читать полностью…