Итак.

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

---

Плюс ActiveMQ в том, что он легко встраивается в приложение (настройка прямо в Spring-овом контексте), интегрируется с Apache Camel (впрочем, Camel должен работать с любым JMS) на котором построена архитектура. Уже используется и уже работает.

Но было обнаружено несколько проблем:

Network of Brokers (который использовался для связи брокеров между собой) работает нестабильно. Пока использовали JDBC хранилище, при сильной нагрузке СУБД (вплоть до таймаутов) почему-то терялись подписчики и постоянно терялась связь между брокерами (возможно, второе и вызывало первую проблему). Возможно, причина всё-таки в коде Camel — непонятно. После перехода на локальное хранилище (Kaha Storage) проблема исчезла.

Без Network of Brokers и с Kaha storage работает под нагрузкой сносно, но нет связи между узлами кластера. При включенном NoB дедлочится. Причём дедлок как-то связан с недостатком ресурсов. Т.е AMQ приостанавливает приём сообщений из-за переполнения некоторого внутреннего курсора, но почему-то при этом не доставляет сообщения (по дампу потоков пока причину установить не удалось).

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

---

Что посоветуете? Наколько надёжно работает JBoss Messaging в условиях большого числа сообщений?

Вкратце — AMQ в кластере просто работает нестабильно. Вот и все. Для одного узла — ок.

Так что вам отсанется только jboss messaging. Не уверен, что легко встроится (запускать нужно будет отдельные процессы возможно), но в продакшн в кластере работает сносно. По крайней мере — работает

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

WFrag wrote:

> Network of Brokers (который использовался для связи брокеров между собой) работает нестабильно.

Просто любопытно — а какой вообще смысл в сети брокеров? Почему бы не
иметь в кластере одну выделенную машину под JMS? В чем соль?

Здравствуйте, mazurkin, Вы писали:

M>Просто любопытно — а какой вообще смысл в сети брокеров? Почему бы не
M>иметь в кластере одну выделенную машину под JMS? В чем соль?

Чтоб не гонять сообщения туда-обратно по сети. Т.е по возможности обрабатываем локально, но если есть незагруженный узел — перебрасываем на него. Плюс если брокер один, а рабочих узлов много, то на узле с брокером уже может понадобится более серьёзный I/O для хранения сообщений. Ещё один небольшой плюс — более простое развёртывание, независимо от узла запускается одно и то же приложение (остальные узлы обнаруживаются автоматически).

Здравствуйте, WFrag, Вы писали:

WF>Насколько я сейчас представляю, проблемы в теории могут решиться грамотной настройкой AMQ. Но учитывая то, что я встречал много нехороших отзывов о AMQ именно в области больших нагрузок, возникла мысль попробовать JBoss Messaging. Насколько я понимаю, его можно встроить в приложение и в кластере он тоже работать умеет. Но я про него ничего не знаю.

насколько я понимаю, встроить jbm легко не получится. если пойдёшь почитать про него на сайте производителя (jboss), то там найдёшь (я ссылку не помню, сам искать не пойду) в т.ч. вопрос-ответ на тему "можно ли запустить jbm отдельно от appserver? — можно, но нереально, ибо требуются сервисы типа jtm, clustering, datasource и т.п.". т.е. теоретически, полагаю, можно обрезать appserver до состояния "только то, что нужно для jbm", но представить себе следующий шаг по встраиванию затрудняюсь ещё больше

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

WF>Что посоветуете? Наколько надёжно работает JBoss Messaging в условиях большого числа сообщений?

у клиента типичная конфигурация redhat 64/java6 64/2 компа с jboss5 в кластере/mysql5. кластер используется для load balancing и failover. некоторые приложения прямо деплоятся, и там есть всего по чуть-чуть, и mdb, и web/ejb. то, чем я занимаюсь, выглядит как отдельное приложение — клиент jms, соответственно, в силу описанных выше причин этому приложению предоставляются 2 instance аппсервера, из возможностей которого используется только кластеризация и jbm. нагрузка варьируется, в некоторых случаях кластеры обрабатывают 2млн jms-сообщений в день (все — persistent типа object среднего объема где-то в районе 1024 байт).

работает это всё не так хорошо, как хотелось бы. основная проблема, которую видим — лажает jboss remoting (основное их решение для транспорта в любых собственных приложениях), с нетерпением ждём очередного патча, каждый раз надеясь, что "ну вот, может быть, наконец-то". в целом, за прошедшие полтора года эксплуатации улучшения видны, но надёжности как не было, так и нет. ежедневные перезапуски — нормальная вещь.

на стороне клиента уже активировали всевозможные конфигурационные приблуды спринга + я уже расширил JmsTemplate для обработки некоторых специальных неожиданных исключений, поднимающихся из недр remoting, чтобы сбрасывать закэшированное jms-соединение. к сожалению, этого недостаточно, т.к. иногда затыкается сам сервер. плюс неоднократно видели странные исключения на стороне сервера, связанные с некорректным перебросом сообщений между нодами кластера (диагностики при этом недостаточно, чтобы понять, реально ли это приводит к потере сообщений, но NPE в логах аппсервера в любом случае расцениваю как их ошибку)

при этом, к сожалению, все эти проблемы трудновоспроизводимы, т.е. создать чёткий падающий test-case не представляется возможным. а на моей домашней кластерной конфигурации win xp 32/ win vista 32/java6 32/mysql5 холостой тестовый вариант работает как часы (за исключением проблем с jgroups, использующихся для синхронизации динамического кластерного представления, для которого пришлось вместо udp multicast включать более кондовый вариант с tcp, почему-то в моей домашней сетке кластерные ноды периодически впадали в состояние тотальной недоговорённости, причём клиенты даже не получали каких-нибудь исключений — просто ждали ответов при jms-вызовах)