CODEWITHSUNDEEP
springjbossjmsibm-mq
enthusiast
enthusiast

Reputation: 395

Spring Message Listener - Connection Refresh

We have implemented a message listener with spring and the container configurations looks like below

    <bean id="customContainer"
        class="org.springframework.jms.listener.DefaultMessageListenerContainer">
        <property name="concurrentConsumers" value="${jms.customContainer.concurrentconsumers}" />
        <property name="maxConcurrentConsumers" value="${jms.customContainer.maxconcurrentconsumers}" />
        <property name="errorHandler" ref="errorHandler" />
        <property name="connectionFactory" ref="jmsQueueConnectionFactory" />
        <property name="destination" ref="listenerQueue" />
        <property name="messageListener" ref="customContainerListener" />
        <property name="receiveTimeout" value="1" />
        <property name="sessionTransacted" value="true" />
        <property name="transactionManager" ref="txManager" />
    </bean>

Its deployed in Jboss and the server log shows the below connection refresh message frequently.

org.springframework.jms.listener.DefaultMessageListenerContainer] (customContainer-3849) Successfully refreshed JMS Connection

It's been reported a high MSU/MIPS utilization at mainframe side where the WebSphere MQ is hosted. Could this be a reason to cause frequent MQ GET calls and increase in utilization?

We haven't specified the message Reply To explicitly, will this be causing a reply to attempt to queue every time? Also the receive timeout is set to 1 ms, does that mean it will be actively polling the queue in every 1 ms? Could someone please explain the concept?

Upvotes: 0

Views: 1604

Answers (2)

JoshMc
JoshMc

Reputation: 10642

The DefaultMessageListenerContainer implements polling of the queue. This means that it issues a GET with a wait of the receiveTimeout. If you have a receiveTimeout of 1ms, that means that every GET call will return after 1ms if no message is on the queue and another GET call will be made. This would appear to the queue manager as back to back GET calls.

Two options:

  1. You can increase receiveTimeout to a higher number which will cause get with wait of the specified value, for example, get with wait of 60000 ms would only do a get every 1 minute or after a message hits the queue. You still get messages off the queue as soon as they are PUT to the queue.
  2. A slightly more efficient option if possible is to switch to the SimpleMessageListenerContainer which will use a native JMS async listener. For IBM MQ this is implemented with the MQ callback functionality. This means the listener registers the callback to the queue manager and the queue manager notifies the listener when new messages land on the queue, so there is no polling.

Upvotes: 3

Carolyn Elkins
Carolyn Elkins

Reputation: 21

Please see https://marketaylor.synology.me/?p=668

Note that the 'contributions' to the CPU consumption - which ultimately impacts the MSU charges are driven by several things that should be controlled. The two biggest are:

  1. The number of connects to/disconnects from the z/OS queue manager. These verbs are the most costly in terms of CPU use in MQ, and should be used judiciously on z/OS because of the cost model. A client application written to connect once and do many MQ actions is going to impact the CPU consumption, but that tends to be predictable and is as they say 'a cost of doing business.' A client application that connects, opens a queue, puts or gets a single message, then disconnects many, many times will drive up costs quickly ( we have seen instances of a 40% uplift in MSU charges in a single month). The latter is called a poorly behaved application.
  2. The use of Temporary Dynamic queues. TD queues require a significant amount of overhead within the queue manager, as the queue infrastructure has to be built up for each new definition and then torn down when the queue is closed. This overhead can be avoided by using statically defined queues and retrieving messages via the correlation ID or message ID. Note that while both these issues are not unique to MQ on z/OS it is the licensing/charging model that makes all the difference.
    Good luck!

Upvotes: 2

Related Questions