Проблема с максимальным количеством соединений MQ

У меня есть клиент Java, который подключается к MQ с 10 подключениями. Они остаются открытыми, пока работает Java-клиент. Для каждого потока мы создаем сообщение, создаем сеанс, отправляем сообщение и закрываем сеанс. Мы используем Spring CachingConnectionFactory и имеем sessionCacheSize, равный 100. Наша инженерная команда MQ сообщила нам, что наш диспетчер очередей имеет максимальное количество подключений 500, и что мы превышаем это значение. Файл QM.ini содержит:

maxChannels=500
maxActiveChannels=256
maxHandles=256

Что я заметил в проводнике MQ, так это то, что количество открытых выходов в очереди остается статичным на уровне 10, однако, если мы балансируем нагрузку между 2 очередями, это 10 в каждой, даже если у нас все еще есть только 10 подключений. Итак, что я хотел бы знать, так это то, что соединения и сеансы jms приравниваются к терминологии MQ?

Я действительно думал, что соединение приравнивается к активному каналу, а сеанс — это дескриптор, поэтому мы, возможно, превышали именно дескрипторы, поскольку количество открываемых (и закрываемых) сеансов исчисляется сотнями или тысячами, тогда как у нас есть только 10 соединения. Хотя это противоречит приведенному ниже фрагменту из технической заметки IBM "Объяснение пула соединений и настройки пула сеансов для фабрик соединений JMS", предполагает, что максимальное количество каналов должно быть больше, чем максимальное количество сеансов, однако мы никогда не знаем этого, поскольку это зависит от нагрузки (если только это не должно быть больше, чем sessionCacheSize?).

Каждый сеанс представляет собой соединение TCP/IP с администратором очередей. С указанными здесь настройками может быть максимум 100 соединений TCP/IP. Если вы используете WebSphere MQ, важно настроить параметр MaxChannels администратора очередей, расположенный в файле qm.ini, на значение, превышающее сумму максимально возможного количества сеансов от каждой фабрики соединений JMS, которая подключается к очереди. менеджер.

Будем признательны за любую помощь в настройке MQ.


person Bazza    schedule 09.07.2014    source источник


Ответы (1)


Предполагая, что для вашего максимального количества диалогов установлено значение 1 на канале MQ (по умолчанию 10 в MQ v7 и v7.5), тогда соединение JMS приведет к соединению TCP (экземпляр канала MQ), а сеанс JMS приведет к другое соединение TCP (экземпляр канала MQ).

Судя по вашему обновлению, у вас настроено 10 подключений JMS, а для параметра sessionCacheSize в Spring установлено значение 100, поэтому 10 x 100 означает создание 1000 потенциальных экземпляров канала MQ. Счетчик открытых выходных данных покажет, сколько «активных» сеансов JMS пытаются отправить сообщение, и не обязательно, сколько из них были «кэшированы».

Совместное использование беседы на канале MQ может помочь вам в этом, так как это определяет, сколько логических соединений может быть совместно использовано через одно TCP-соединение (экземпляр канала MQ). Таким образом, 10 диалогов по умолчанию означают, что вы можете создать 10 сеансов JMS, которые работают только через одно TCP-соединение.

person whitfiea    schedule 09.07.2014
comment
Привет, спасибо за ответ. Извините за невежество, но относится ли максимальное количество разговоров к максимальному количеству каналов или к максимальному количеству активных каналов в файле qm.ini, или ни к одному из них? Именно эти свойства мы, кажется, превышаем. Создается ли TCP-соединение для создания сеанса только при нарушении лимита сеансов или это происходит для всех сеансов? Кроме того, у нас есть один экземпляр CachingConnectionFactory, все соединения создаются из него, является ли размер кэша сеанса для каждого соединения (в отличие от 100 для всех соединений)? - person Bazza; 09.07.2014
comment
Максимальное количество каналов означает, сколько каналов вы можете определить в диспетчере очередей. Принимая во внимание, что Max Active Channels означает, сколько экземпляров каналов может быть активным в диспетчере очередей. Максимальное количество диалогов — это свойство самого канала, которое определяет, сколько различных логических соединений может быть мультиплексировано в одном экземпляре канала. Свойства qm.ini будут распространяться на весь диспетчер очередей, поэтому может быть больше, чем просто подключение вашего приложения. Вы должны спросить своего администратора MQ, сколько экземпляров канала используется для канала. - person whitfiea; 09.07.2014
comment
Да я вижу. Так является ли sessionCacheSize для одного CachingConnectionFactory общим для всех соединений (то есть 100 для 10 соединений) или для каждого соединения (1000) в этом случае? - person Bazza; 09.07.2014
comment
Читая документ Spring для более подробной информации, единственное, что он говорит, это то, что кеш «для каждого типа сеанса JMS». Поэтому я не могу точно сказать, является ли это кешем для каждого соединения JMS, созданного с использованием этого CachingConnectionFactory, или для всего CachingConnectionFactory, это звучит как еще один вопрос SO, который нужно задать. - person whitfiea; 09.07.2014
comment
Да, я пришел к такому же выводу. - person Bazza; 09.07.2014