Есть несколько способов взглянуть на это. С точки зрения вашего приложения одна фабрика соединений может иметь много сессий. У каждого сеанса может быть много потребителей, но единицы работы ограничены для каждого сеанса, а не для каждого потребителя. Так что, скорее всего, вам нужна одна фабрика соединений с несколькими сессиями, где у каждого сеанса есть слушатель по определенной теме. Если у вас есть прослушиватель, назначенный нескольким потребителям в одном сеансе, любое подтверждение (или COMMIT в транзакционном сеансе) фиксирует все сообщения, полученные или помещенные в этот сеанс.
С точки зрения сервера WMQ, одно определение канала может иметь много запущенных экземпляров. Таким образом, вам нужен только один канал SVRCONN, определенный для приложения, независимо от того, сколько экземпляров канала необходимо запустить. Старайтесь не размещать разные приложения на одном SVRCONN, потому что вы часто хотите администрировать или авторизовать приложения отдельно. Например, с помощью приложений на отдельных каналах вы можете легко определить, какое приложение работает неправильно, если вдруг обнаружите, что у вас 3000 запущенных каналов.
В целях администрирования и отладки у меня, вероятно, будет один CF для стороны приложения и один CF для стороны обслуживания. Каждый из них будет указывать на другой канал SVRCONN, как описано выше. Внутри сервера приложений я бы придерживался одной темы за сеанс, если только ваше приложение не может использовать несколько тем в одной единице работы. В подписке вы можете указать тему подстановки, чтобы получить все темы ниже определенной точки в дереве тем с одним подписчиком.
Только для передового опыта, я бы также настроил CF на использование FAILIFQUIESCE, чтобы убедиться, что QMgr может быть остановлен упорядоченным образом, и я бы использовал SYNCPOINTALLGETS (или сеанс транзакции с явными вызовами фиксации) для улучшения надежность в соответствии со спецификацией JMS 1.1, версия 4.4.13, которая гласит:
Если сбой происходит между временем, когда клиент фиксирует свою работу в сеансе, и методом фиксации возвращается, клиент не может определить, была ли транзакция зафиксирована или откатана. Та же неоднозначность существует, когда происходит сбой между нетранзакционной отправкой сообщения PERSISTENT и возвратом из метода отправки. Решение этой неоднозначности зависит от приложения JMS. В некоторых случаях это может привести к тому, что клиент будет создавать функционально повторяющиеся сообщения.
Сообщение, доставленное в результате восстановления сеанса, не считается повторяющимся сообщением.
SYNCPOINTALLGETS (a.k.a. SPAG) гарантирует, что сообщения, извлеченные из очереди, будут доставлены в ваше приложение, прежде чем они будут зафиксированы и окончательно удалены из очереди. В противном случае, если вы потеряете соединение, пока QMgr пытается вернуть сообщение, оно исчезнет навсегда. С установленным SPAG вы можете увидеть одно и то же сообщение дважды, как описано в спецификации JMS, но вы никогда не потеряете его.
Подробнее о параметрах, доступных для объектов CF, очереди и тематики, см .: Свойства объектов в руководстве по WebSphere MQ Using Java.
WMQ v6.0 по состоянию на сентябрь 2012 года является устаревшим, поэтому, пожалуйста, не забудьте разработать с использованием клиентов v7, даже если сервер находится на v6. Это уменьшит ваши усилия по миграции в следующем году. Загрузите клиент v7 здесь и клиент WMQ v7.1 здесь .