Вышел RabbitMQ 3.0.0

а для чего его на практике можно использовать?

Я использую для работы Celery.

одной из популярнейших систем передачи сообщений

впервые слышу

как то Crossroads I/O больше нравитсяб, и лицензия LGPL

продолжай оставаться в криокамере, бро.

Шины интеграции не на таких ли системах строятся? Я сам хотел использовать RabbitMQ для интеграции продуктов на предприятии, да не успел реализовать. А теперь не актуально.

а для чего его на практике можно использовать?

В качестве менеджера очередей для крупного проекта.

одной из популярнейших систем передачи сообщений

в каких широких кругах оно популярнейшее? желтые тексты новостей достали

Хорошая новость, мы его используем. Надо поиграться с новой версией.

в веб-морде на странице queues по-прежнему нет сводной информации по числу консьюмеров?

Разработчики призывают всех пользователей обновиться до новой версии

Разработчики всё никак не придумали, как обновиться до новой версии без даунтайма? Кластер, итить...

Юзаю пока кролика, но посматриваю на nsq. Там гораздо более похоже на кластер по сути, чем это поделие.

Для передачи сообщений между узлами системы

изменений, конечно, вагон.

это не ещё одна асечка. вот поэтому и впервые слышишь.

Полезная вещь, читал про неё, хоть и не приходилось использовать.

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

Тогда нужно было описывать соответственно, а не как асечка+.

Тогда нужно было описывать соответственно, а не как асечка+

асечка это система интернет-пейджинга а не «система сообщений»

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

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

А сходить в гугл уже не модно? :)

Хотя, правильно говорят: «если вы не знаете, что это такое, вам это не нужно»

интернет-пейджинга

Это из прошлого века, так никто не говорит.

До модераторов пробрался, а как новости правильно оформлять не удосужился узнать. Они должны быть написаны так, чтобы в гугл ходить не надо было. Возможно для тебя это новость.

это да, автор «постарался»

пример внедрения «на пальцах» не помешал бы.

> а для чего его на практике можно использовать?
В качестве менеджера очередей для крупного проекта

В крупном проекте сабж сожрёт всю память и, живя на отдельных серверах, успешно грохнется, попутно уронив весь кластер. До сих по не ясно, почему дисковые очереди у сабжа так сильно жрут RAM. Годиться только как диспатчер сообщений с короткими очередями для получателей.

спасибо, кэп

Rabbit vs 0 vs AM что выберешь?

Используем кролика в своих проектах (Python, PHP, C++) для горизонтального масштабирования. Других AMQP систем не использовали, так что сравнивать не с чем. И да, пользователям асечки оно не нужно :)

Когда понадобилось сделать очереди на кластере и уйти от rabbitmq, то быстренько налабал свой костыль под специфику конкретной задачи.

Rabbit vs 0 vs AM что выберешь?

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

Остальных двух не юзал, но
- ZeroMQ можно использовать в около-рапределенном режиме, без совсем единых точек отказа.
- Apache ActiveMQ - выглядит как монстроклон rabbitmq, только на джаве. Нужен ли аналог, если есть оригинал?

Что выберу зависит от задачи. Под мои задачи обычно не подходит вообще ничего из amqp.

На сайте самый первый пример показывает как использовать это в качестве асечки.

До модераторов пробрался, а как новости правильно оформлять не удосужился узнать. Они должны быть написаны так, чтобы в гугл ходить не надо было. Возможно для тебя это новость.

Несколько секунд - и читаешь об этом в wiki. Зачем замусоривать текст новости?

пока я не базировал свой проект на ZeroMQ... имеет ли смысл попробовать RabbitMQ? убедите меня :)

А erlang очевидно был выбран, чтоб способствовать более быстрому глобальному потеплению.

В крупном проекте сабж сожрёт всю память и, живя на отдельных серверах, успешно грохнется, попутно уронив весь кластер. До сих по не ясно, почему дисковые очереди у сабжа так сильно жрут RAM. Годиться только как диспатчер сообщений с короткими очередями для получателей.

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

эта технология вроде jms что ли?

В крупном проекте сабж сожрёт всю память и, живя на отдельных серверах, успешно грохнется, попутно уронив весь кластер

УМВР

Сделай именно очереди, чтоб по 100000(0) элементов в сотне очередей.

Тут эрланг не при чём. Ключи всех элементов очередей храняться в RAM для быстродействия. Если очередь станет большой, то приехали.

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

Ключи всех элементов очередей храняться в RAM для быстродействия. Если очередь станет большой, то приехали.

или там хранить указатели на очереди ))

Согласен - юзать как брокер. Он собственно так и позиционируется.

остаются свои велосипеды писать или шуструю базу задействовать + с имитацией очередей.

пока я не базировал свой проект на ZeroMQ... имеет ли смысл попробовать RabbitMQ?

Гхм, это какбы совершенно разные весовые категории. Что за проект (хотя сама постановка вопроса, мягко говоря, настораживает :))?

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

вот как-раз иммутабельность и требует копию данных на каждый чих. а «легковесными» их назвали, чтобы усыпить вашу бдительность.

Кролик юзает мнезию :(

Но проблем с производительностью у него я не замечал. За выжиманием памяти тоже вроде замечен не был. Хотя длинных очередей (по 100к элементов) у меня не собирается

копию данных на каждый чих

Да, это бесспорный оверхед. Но это нормально для ФП-языков и так даже удобнее в некоторых случаях (не во всех конечно) программировать. Еще приходится из-за этого таскать везде с собой кучу параметров. Если хочется ООП - есть молодой exlixir полностью ооп на базе ерланга с его плюшками. Считается, что благодаря иммутабельности проблемы утечки памяти сведены к минимуму, но самом деле это не совсем так.

«легковесными» их назвали, чтобы усыпить вашу бдительность.

Там все есть процесс, так что без легковесности сложно что-либо сделать. Процессы сабжа реально дешевые и let it crash.

чтобы усыпить вашу бдительность.

т.е. они на самом деле не легкие, а тяжелые?

Кролик юзает мнезию :(

Кролик, ёж.. )) да, с ней не соскучишься. На сайте кролика насчет мнезии как-то уклончиво упоминается. Если это возможно, то лучше в этом случае использовать т.н. без-дисковые схемы и только RAM-nodes (в терминах мнезии)

Но проблем с производительностью у него я не замечал. За выжиманием памяти тоже вроде замечен не был. Хотя длинных очередей (по 100к элементов) у меня не собирается

Это хорошо. Кому как повезет с нагрузкой проекта ))

И чем это лучше JMS?

И чем это лучше JMS?

Протокол AMQP проще JMS и кроме того он кросс-платформенный. Помню года 4 назад пробовал играться с ним, когда затра...ся с кривой кластеризацией ActiveMQ. Но потом меня сократили и с тех пор я с мессанджингом особо не работал. RabitMQ более подходит для High Speed Messaging and Low Latency чем JMS

почему дисковые очереди у сабжа так сильно жрут RAM.

О, ты с имел опыт его использования. Не подскажешь, насколько «сильно жрут» память и диск? Прямо сейчас перевожу свой проект на RabbitMQ с хранимыми очередями и «ручным» подтверждением (с собственного костыля поверх MongoDB), инетерсно узнать про косяки.

Я его использую. Сомневаюсь, что это правильный подход, но у меня прижился. Очередь в 2.5 Млн сообщений быстро создается (где-то 600Мб занимает) и потом разгребается пачкой воркеров в течение 5-6 часов. Очередь персистентная, в первую очередь для защиты от сбоев. Как персистентность влияет на потребление памяти я не помню.

Когда кролик начинает занимать что-то около 50% памяти он принудительно ограничивает скорость паблишинга сообщений через TCP backpressure, чтобы не уходить в swap.

Насчет копии данных на каждый чих не совсем верно.

Если меняешь кортеж, то «копируется» только сам кортеж (не рекурсивно). Если меняешь значение в кортеже/рекорде, то «копируется» только это значение и сам контейнер. При добавлении элементов к связному списку (и к строке, соответственно) вообще НИЧЕГО не копируется. За счет поддержки IO листов склейка строк происходит крайне эффективно и тоже без копирований. Большие бинарные блобы хранятся в отдельной куче и не копируются при передаче сообщений.

Насчет персистентного хранилища кролика завтра посмотрю.

Процессы легкие. При старте занимает ~309 машинных слов. Стек динамический, так что, в случае чего, stack overflow не словишь пока в своп не уйдёшь.

Имеешь в виду функцию BIF erlang:setelement ?

это в общем плане и теории считается, что создается копия - конечно, все это оптимизируется. Например при работе с dict - постоянно происходит перечитывание при вызове API этого модуля - сначала это удивляет, потом не обращаешь внимание уже )) При изменения словаря, создается фактически новая (измененная) копия словаря, хотя внутренняя структура словаря - кортеж. Или когда работает gen_fsm, gen_server - его state постоянно «крутится», изменяясь практически полностью при запросах handle_call, но это уже зависит от логики сервера. Если тем более case может вернуть все что угодно в handle_call при обновлении state. Кортэжи считаются более компактными по потреблению памяти, чем списки.

При добавлении элементов к связному списку

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

Немного другое