Максимальное количество очередей JMS - PullRequest
3 голосов
/ 01 октября 2011

У нас есть приложение, которое имеет 1) пользовательский сервер (обычный ServerSocket), который отвечает на 2) приложения / апплеты Java SWING, работающие на клиентских рабочих столах.

У нас более 140 таких пользовательских серверов (выделенных для каждой группы клиентов Swing).Мы создали административное приложение для управления запусками, выключениями и другими задачами сервера.Для связи между приложением Admin и сервером мы создаем приложение JMS.Из-за большой нагрузки на сервер мы не размещаем этот JMS на одном блоке, поэтому мы оставили возможность иметь отдельный блок JMS.Мне нужна отдельная очередь для каждого сервера.

Мой вопрос: можем ли мы иметь более 140 очередей JMS на одном сервере приложений.Если да, то какая должна быть идеальная конфигурация оборудования.Если нет, то что вы предлагаете.

Спасибо

Ответы [ 3 ]

3 голосов
/ 01 октября 2011

Я нашел эту интересную статью некоторое время назад:

[ActiveMQ] Сбой брокера после открытия 700 очередей на узле из-за слишком большого количества открытых файлов - очевидно, у него есть временный файл для каждой очереди и открытый файл для каждого JAR (из которых 124!) И 60 разных файловых дескрипторов. Количество открытых файлов не уменьшается при выходе из клиента. Некоторые поиски в Google подразумевают, что в ActiveMQ имеется множество ошибок, связанных с утечкой файловых дескрипторов.

2 голосов
/ 04 октября 2011

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

также, если вы используете KahaDB 5.3+, то он оптимизирован для использования меньшего количества файловых дескрипторов и т. Д. ...

1 голос
/ 03 октября 2011

Я отвечу только на часть «если нет».

При необходимости вы можете уменьшить количество очередей, используя селекторы сообщений.Группа серверов может отправляться в одну очередь и идентифицироваться свойством сообщения.Вы, безусловно, должны уже определить его - IP-адрес, URL-адрес, который однозначно идентифицирует сервер.

Это решение в крайнем случае, поскольку отдельные очереди можно отслеживать лучше.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...