Пул соединений IBM MQSeries с Tomcat - PullRequest
Новая
       8

Пул соединений IBM MQSeries с Tomcat

0 голосов
/ 06 ноября 2018

Мы пытаемся установить соединение jms от tomcat к IBM MQSeries с целью создания пула соединений.

Мы перешли по ссылке ниже с предложенным решением:

Пул соединений WebSphere MQ с Tomcat

Я не знаю, как мы можем управлять различными соединениями jms с помощью предложенного метода, мы провели тесты и заметили, что CachingConnectionFactory управляет другим сеансом jms, а не соединением jms.

Я делюсь с вами ссылкой ниже, в которой поясняется, что CachingConnectionFactory не позволяет управлять различными соединениями jms, а только сеансами jms!

https://jira.spring.io/browse/SPR-13586

Я также поделюсь с вами обоими файлами context.xml (datasource и services.xml (файл весенних сервисов)

context.xml 

<Resource name="jms/AN8.NOTI.MOBILE.01" auth="Container" type="org.springframework.jms.connection.CachingConnectionFactory" 
    factory="com.cl.fwk.jms.utilities.RSFCachingMQQueueConnectionFactoryFactory" 
    description="JMS Queue Connection Factory for sending messages" HOST="**********" 
    PORT="****" CHAN="******" TRAN="*" QMGR="***" />

<Resource name="jms/MQAN8.NOTI.MOBILE.01" auth="Container"
    type="com.ibm.mq.jms.MQQueue" factory="com.ibm.mq.jms.MQQueueFactory"
    description="JMS Queue for receiving messages from Dialog" QU="********" />

services.xml 

<!-- Ressource JNDI pour la connexion MQSeries-->
<bean id="xxxx.jmsRefConnectionFactory.mqseries" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:comp/env/jms/AN8.NOTI.MOBILE.01" />
    <property name="resourceRef" value="true" />
</bean>

<!-- Ressource JNDI pour la file d'attente du broker MQSeries-->
<bean id="xxxx.jmsRefQueue.mqseries" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:comp/env/jms/MQAN8.NOTI.MOBILE.01" />
    <property name="resourceRef" value="true" />
</bean>
<!-- A cached connection to wrap the MQSeries connection -->
<bean id="xxxx.jmsConnectionFactory.mqseries" class="org.springframework.jms.connection.CachingConnectionFactory">
    <!-- <constructor-arg ref="xxxx.jmsRefConnectionFactory.mqseries" /> -->
    <property name="targetConnectionFactory" ref="xxxx.jmsRefConnectionFactory.mqseries"/>
    <property name="sessionCacheSize" value="10" />
</bean>

<bean id="xxxx.jmsDestinationResolver.amq" class="org.springframework.jms.support.destination.DynamicDestinationResolver" />

<bean id="xxxx.jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
    <property name="connectionFactory" ref="xxxx.jmsConnectionFactory.mqseries" />
    <property name="defaultDestination" ref="xxxx.jmsRefQueue.mqseries" />
    <property name="destinationResolver" ref="xxxx.jmsDestinationResolver.amq" />
    <property name="sessionTransacted" value="true" />
    <property name="sessionAcknowledgeMode" value="#{T(javax.jms.Session).AUTO_ACKNOWLEDGE}" />
</bean>

С уважением.

1 Ответ

0 голосов
/ 10 ноября 2018

Резюме

Вам необходимо либо перейти на более позднюю версию классов MQ для JMS, либо попросить администратора MQ увеличить параметры MAXINST / MAXINSTC, чтобы разрешить большее количество экземпляров канала.

Обратите внимание, что используемая вами версия больше не поддерживается с 2012 года, поэтому я бы порекомендовал обновить ее. 

Product        Version  Release      End of Service
============   =======  ==========   =================
Websphere MQ   6.0      2005-06-24   2012-09-30

ОБЩАЯ ИНФОРМАЦИЯ ИЗ КОММЕНТАРИЙ

На основании того, что вы указали в комментариях, о вашей текущей настройке известна следующая информация: 

IBM MQ Server version: 8.0.0.? (specific maintenance level unknown)
IBM MQ jar names: mq-7.0.0.jar and mqjms-7.0.0.jar
IBM MQ jar version: 6.0.2.11
SVRCONN Channel settings: SHARECNV(10) MAXINST(9) MAXINSTC(9)

Обратите внимание, что, хотя у файлов jar есть имена, содержащие строку 7.0.0, на самом деле они относятся к IBM MQ v6.0.2.11 (технически это называлось Websphere MQ в то время).

Другой вопрос StackOveflow « Пул соединений WebSphere MQ с Tomcat », на который вы указываете, ссылается на тот факт, что IBM MQ до v7.0 (например, v6.0) предоставил пул соединений, но это был удален в MQ v7.0 и спрашивал, как получить аналогичную функциональность в v7.0 и более поздних версиях.

Пул соединений v6 был по умолчанию в MQ v6.0 JMS, как описано на стр. 504 руководства " WebSphere MQ Using Java Version 6.0 ":

setUseConnectionPooling

public void setUseConnectionPooling(boolean usePooling);

Выбирает, использовать ли пул соединений. Если вы установите это значение true, JMS обеспечивает пул соединений на время жизни любых соединений созданный через ConnectionFactory. Это также влияет на соединения создан с параметром usePooling, установленным в false; отключить пул соединений во всей JVM убедитесь, что все фабрики соединений, используемые в В JVM для usePooling установлено значение false.

Тот факт, что пул соединений был удален в MQ v7, задокументирован на странице Центра знаний IBM MQ v8.0 Разработка приложений> Разработка приложений JMS и платформы Java, Enterprise Edition> Использование классов IBM MQ для JMS> Классы IBM MQ для JMS> Класс MQConnectionFactory

setUseConnectionPooling

public void setUseConnectionPooling(boolean usePooling)

Устаревшее. JMS больше не использует пул соединений. Любой пул соединений должно быть сделано с использованием средств, предоставляемых сервером приложений. Установите использование ConnectionPooling в более ранних версиях классов WebSphere MQ для JMS. Этот метод сохранен для совместимости со старыми MQJMS приложения, но, потому что эта функциональность пула подключений имеет был удален из версии 7, установка этого свойства не будет эффект.

Чтобы объяснить поведение, которое вы видите сегодня, вам также необходимо знать о поведении общих бесед на канале MQ Client, которое было добавлено в MQ v7.0, вы можете прочитать об этом на странице Центра знаний IBM MQ v8.0 Миграция и обновление> Введение в миграцию IBM MQ> Сосуществование, совместимость и функциональная совместимость> Клиент MQI: поведение по умолчанию каналов клиентского соединения и соединения с сервером . Приведу несколько подробностей ниже:

В версии 7.0 настройки по умолчанию для подключения клиента и сервера каналы изменены, чтобы использовать общие разговоры. Это изменение влияет на поведение сердцебиения и каналов выходит, и может оказать влияние на производительность.

До версии 7.0 каждый разговор был выделен Экземпляр канала. Начиная с версии 7.0, по умолчанию для клиента и сервера соединения, чтобы разделить канал MQI. Вы используете SHARECNV (обмен разговоры) параметр для указания максимального количества разговоры, которые могут быть переданы через определенный клиент TCP / IP Экземпляр канала. Возможные значения:

SHARECNV (0)

  • Это значение указывает на отсутствие совместного использования разговоров через сокет TCP / IP. Экземпляр канала ведет себя точно так же, как если бы он был версией 6.0 канал подключения к серверу или клиенту , и вы не получаете дополнительные функции, такие как двунаправленные пульсации, которые доступны при установите SHARECNV на 1 или выше. Используйте значение 0, только если у вас есть существующие клиентские приложения, которые не работают правильно при установке SHARECNV до 1 или выше.

Собрав все это вместе, вы получите канал SVRCONN со следующими настройками:

  • SHARECNV(10)
  • MAXINST(9)
  • MAXINSTC(9)

Эти настройки при использовании с клиентом MQ v7.0 и более поздними версиями означают, что между клиентом и администратором очередей может быть 9 экземпляров канала (TCP-соединений), и каждый из них может иметь 10 общих разговоров, всего до 90 разговоры.

Поскольку вы используете классы MQ v6.0 для JMS, канал работает так, как если бы параметр был:

  • SHARECNV(0)
  • MAXINST(9)
  • MAXINSTC(9)

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

В классах MQ v6.0 для JMS каждое нижележащее соединение JMS и каждый сеанс JMS, создаваемый поверх соединения JMS, будут выделять экземпляр канала для администратора очередей.

Чтобы больше узнать о том, как соединения и сеансы взаимодействуют друг с другом и с настройкой SHARECNV, посмотрите страницу центра знаний IBM MQ v8.0 Разработка приложений> Разработка приложений JMS и Java Platform, Enterprise Edition> Использование IBM MQ классы для JMS> Написание классов IBM MQ для приложений JMS> Доступ к функциям IBM MQ> Совместное использование соединения TCP / IP в классах IBM MQ для JMS :

Каждое соединение JMS и сеанс JMS, которые создаются приложением JMS, создают свой собственный диалог с администратором очередей.

В вашем случае, поскольку вы используете классы MQ v6.0 для JMS, каждый "разговор" является экземпляром канала MQ (TCP-соединение) с администратором очередей.

Я бы порекомендовал вам использовать текущие классы IBM MQ для версии Java, что позволит вам иметь до 90 общих бесед. Если проблема вызвана конфликтами, вам нужно, чтобы администратор MQ увеличил настройки MAXINST / MAXINSTC и уменьшил SHARECNV.

Для IBM MQ Classes для JMS вы можете найти список необходимых файлов на странице Центра знаний IBM MQ v9 " Что установлено для классов IBM MQ для JMS ":

Перемещаемые файлы JAR
Внутри предприятия следующие файлы могут быть перемещены в системы, которые должны запускать классы IBM MQ для JMS:

  • com.ibm.mq.allclient.jar
  • com.ibm.mq.traceControl.jar
  • jms.jar
  • fscontext.jar
  • providerutil.jar
  • Служба безопасности Bouncy Castle и поддержка CMS

Файлы fscontext.jar и providerutil.jar требуются, если ваше приложение выполняет поиск JNDI с использованием контекста файловой системы.

Требуется Jar-файлы, предоставляемые поставщиком безопасности Bouncy Castle и поддержкой CMS. Дополнительную информацию смотрите в разделе Поддержка JRE не IBM.

Обратите внимание, что только com.ibm.mq.allclient.jar, jms.jar, а также провайдер безопасности Bouncy Castle и JMS поддержки включены в распространяемый клиент, но все они включены в клиент Java All. Вы также используете 9.0.0.0, и я бы порекомендовал вам перейти на 9.0.0.5. На Fix Central .

можно найти как распространяемых клиентов, так и клиентов Java All.
...