如何为WMQ配置(弹簧)JMS连接池 [英] how to configure (spring) JMS connection Pool for WMQ

问题描述

我正在尝试在spring/camel中为Websphere MQ配置JMS连接池.当尝试从Spring使用CachingConnectionFactory时，我看到类强制转换异常.无法从WMQ中找到一个池，是否有人与WMQ完成了连接池，我没有找到任何示例. ActiveMQ有很多示例.

I am trying to configure a JMS connection pool in spring/camel for Websphere MQ. I am seeing class cast exception, when tried to use CachingConnectionFactory from spring. Could not find a pool from WMQ, have anybody done connection pooling with WMQ, i didnt find any examples. There are lot of examples for ActiveMQ.

到目前为止，这是产生类强制转换异常的原因.

here is what i have so far, that is producing class cast exception.

<bean id="inCachingConnectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory">
    <property name="targetConnectionFactory" ref="inboundMqConnectionFactory1" />
    <property name="sessionCacheSize" value="5" />
</bean>

<bean id="inboundWebsphereMq1" class="org.apache.camel.component.jms.JmsComponent">
    <property name="connectionFactory" ref="inCachingConnectionFactory" />
    <property name="destinationResolver" ref="jmsDestinationResolver" />
    <property name="transacted" value="true" />
    <property name="transactionManager" ref="txManager1" />
</bean>

<bean id="inboundMqConnectionFactory1" class="com.ibm.mq.jms.MQQueueConnectionFactory">
    <property name="hostName" value="${isi.inbound.queue.host2}" />
    <property name="port" value="${isi.inbound.queue.port}" />
    <property name="queueManager" value="${isi.inbound.queue.queuemanager2}" />
    <property name="channel" value="${isi.inbound.queue.channel2}" />
    <property name="transportType" value="${isi.queue.transportType}" />
</bean>

我看到的异常在这里

试图恢复.原因:com.sun.proxy.$ Proxy37无法转换为com.ibm.mq.jms.MQQueueSession

trying to recover. Cause: com.sun.proxy.$Proxy37 cannot be cast to com.ibm.mq.jms.MQQueueSession

推荐答案

通常:

• 请勿使用 QueueConnectionFactory 或 TopicConnectionFactory ，因为 ConnectionFactory (JMS 1.1)替代了两者
• v7 WMQ JMS客户端jar中的每个ConnectionFactory都各自提供缓存逻辑，因此通常不需要CachingConnection Factory.

• do not use QueueConnectionFactory or TopicConnectionFactory, as ConnectionFactory (JMS 1.1) is replacement for both
• Each ConnectionFactory from v7 WMQ JMS client jars provide caching logic on each own so in general you don't need CachingConnection Factory.

现在尝试这种方式:

<bean id="mqConnectionFactory" class="com.ibm.mq.jms.MQConnectionFactory"
  p:queueManager="${QM_NAME}"
  p:hostName="${QM_HOST_NAME}"
  p:port="${QM_HOST_PORT}"
  p:channel="${QM_CHANNEL}"
  p:clientID="${QM_CLIENT_ID}">
  <property name="transportType">
    <util:constant static-field="com.ibm.msg.client.wmq.WMQConstants.WMQ_CM_CLIENT" />
  </property>
</bean>

<bean id="userConnectionFactory" class="org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter"
  p:targetConnectionFactory-ref="mqConnectionFactory"
  p:username="${QM_USERNAME}"
  p:password="${QM_PASSWORD}" />

<!-- this will work -->
<bean id="connectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory"
  p:targetConnectionFactory-ref="userConnectionFactory"
  p:cacheConsumers="true"
  p:reconnectOnException="true" />

如果您愿意的话，当然可以缓存会话，而不是使用方.以我的经验，WMQ会话缓存是可衡量的性能改进，但前提是您在WMQ机器上的CPU能力或实际消息吞吐量受到限制.两种情况在世界上大多数应用中都很少见.缓存使用者避免了过多的MQ OPEN调用，这在WMQ上是昂贵的操作，因此也有帮助.

Of course you can cache sessions instead of consumers if you want it that way. By my experience WMQ session caching is measurable performance improvement but only if you are limited on CPU power on WMQ machine or by actual message throughput; both situations are rare in majority of world applications. Caching consumers avoids excessive MQ OPEN calls which is expensive operation on WMQ so it helps too.

我的经验法则是消费者+会话缓存的性能优势等于连接缓存的性能优势的1/2，除非您受硬件限制，否则在您日常的JEE堆栈中通常不会浪费时间.

My rule of the thumb is consumer + session caching performance benefit is equal to 1/2 of performance benefit of connection caching and usually not wort of pursuing in your everyday JEE stack unless you are hardware limited.

自WMQ v7起，与弹簧MC相比，异步使用方的确非常快，几乎没有CPU开销，并且如果您受硬件限制，则是使用消息的首选方式.大部分时间我仍然喜欢使用Spring，因为我更喜欢它随和的性质.

Since WMQ v7, asynchronous consumers are realy realy fast with literally no CPU overhead when compared to spring MC, and are preferred way of consuming messages if you are HW limited. Most of the days I still use Spring as I prefer its easy-going nature.

希望有帮助.

这篇关于如何为WMQ配置(弹簧)JMS连接池的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！