Мы сталкиваемся с проблемами в производстве, используя DefaultMessageListenerContainer Spring для извлечения и обработки MQ-уведомлений.
Мы думаем, что количество базовых соединений TCP / IP может быть проблемой.
Iнеобходимо лучше понять, как клиент IBM MQ и Spring JMS создают соединения TCP / IP.
Подробности:
Мы используем DefaultMessageListenerContainer для получения сообщений из IBM MQ. Мы используем SingleConnectionFactory для использования одного общего JMS-соединения и используем CACHE_SESSION для каждого сеанса JMS для каждого потока. У нас concurrentConsumers установлен на 10 с maxConcurrentConsumers на 20.
Я бы ожидал, что при высоких нагрузках с 20 maxConcurrentConsumers у нас будет 20 открытых соединений TCP / IP кменеджер очередей, но мы, кажется, выше, чем это. Я думал, что было одно соединение TCP / IP для каждой сессии JMS, но я думаю, что это ошибочное понимание.
(На самом деле у нас есть 5 различных каналов MQ для потребления и применения одной и той же конфигурации 10-20 потребителей и около 330 соединений TCP / IP во время обычного объема. Я буду отслеживать это со временем, но я верюон всплывает во время восстановления. Кроме того, есть 2 из 5 каналов MQ, которые имеют более высокую громкость, чем другие 3, и это те, на которых мне нужно сосредоточиться и увеличить их при уменьшении других, но следующий эффект будет ото же самое)
В настоящее время мы тестируем различные параметры конфигурации и нагрузочное тестирование, чтобы увидеть, что мы можем обнаружить.
Кажется, что главная проблема заключается в том, что у нас может быть 10 минут, когда мы не можем обработатьчто-нибудь, а затем мы автоматически восстанавливаемся, но объем таков, что нам требуется много времени, чтобы вернуться в актуальное состояние, что влияет на SLA.
В частности, мы видим ошибки, подобные следующим в течение дня:
JMSCMQ0001 IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2538' ('MQRC_HOST_NOT_AVAILABLE')
Spring восстанавливает вывод «Успешно обновленное соединение JMS», но, как уже упоминалось, мы выполняем условие несколько раз в неделю, так чтообъем сообщений MQ - мы не можем догнать maxConcurrentConsumers.