Question

A customer uses this pattern:

• Apache Camel and CXF JMS receivers
• These internally use Spring MDPs (message-driven POJOs) to implement their message receivers
• They are deployed on IBM WebSphere Application Server 7
• The queue manager is IBM Websphere MQ 6
• The Spring MDPs are bound to the queue manager using JNDI Queue Connection Factories — with support for connection pooling and session pooling

Here is an example of such message receiver, this one is using Camel:

<bean id="ibmmq" class="org.apache.camel.component.jms.JmsComponent">
    <property name="configuration" ref="jmsConfig"/>
</bean>

<!-- JNDI reference to the queue manager -->
<jee:jndi-lookup id="myTargetConnectionFactory" jndi-name="${mq.queueconnectionfactory}"/>

<bean id="jmsDestResolver" class="org.springframework.jms.support.destination.JndiDestinationResolver"/>

<bean id="myConnectionFactory" class="org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter">
    <property name="targetConnectionFactory" ref="myTargetConnectionFactory"/>
    <property name="username" value="SOME_USER"/>
    <property name="password" value=""/>
</bean>

<bean id="jmsConfig" class="org.apache.camel.component.jms.JmsConfiguration">

    <property name="connectionFactory" ref="${mq.connectionfactorybean}" />        
    <property name="destinationResolver" ref="jmsDestResolver" />        
    <property name="concurrentConsumers" value="1" />
    <property name="maxConcurrentConsumers" value="1" />

    <!--
        NOTE: If we try to use a cache without a transactionManager we get "Connection closed" errors
    -->
    <property name="cacheLevelName" value="CACHE_NONE" />
</bean>

Problem: the WebSphere MQ administrators are reporting lager number of MGET() requests against the queue manager. The hypothesis at the moment is that those receiver are constantly polling the channel for new messages.

They do not seem to have this problem with MDBs (message-driven beans). Is the MDP async implementation really a polling mechanism? If so, is there a way to limit the trips to the queue manager? Perhaps increasing the polling interval? Any insights would be appreciated.

Answer 1

I am not sure about CXF, but for Camel listeners:

It seems like a default JMS consumer in the JmsConfiguration is of type “Default”.
The means, it will implement a DefaultMessageListenerContainer from Spring.

From Javadoc

Message listener container variant that uses plain JMS client API, specifically a loop of MessageConsumer.receive() calls

Receive calls would map to MQ GET calls.

There is also the option to specify a Simple type of consumer, which I guess is what you want.

Message listener container that uses the plain JMS client API’s MessageConsumer.setMessageListener()

I am not sure here, but the Spring docs indicate that the simple message listener container does not support XA transactions. That might be something to consider, since you are running inside an application server.