У меня есть клиент 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.