100分钟后，websphere mq客户端主题静默访问错误

Question

We're integrating communication using topics in WebSphereMQ. Using ac# library for MQ, version 8, dll's are from mqc8_8.0.0.3_win64.zip downloaded from official IBM website. We connect to the server without a problem, then we access a specified topic, we set the connection as durable, provide the userID. Then we enter an infinite loop asking every 2 minutes if there are new messages published in this topic. This works great. If the client publishes messages - we get them. If we get disconnected without removing the subscription, we can resume it after reconnection and messages are there. Connection wise it seems ok.

The problem is that after some semi iddle time (just asking for new message, but every time reciving code 2033 - no new messages) something stops working. There is however no other (such as network) error code. We continuously get code 2033, but we can no longer receive messages even if they are put there. If we disconnect (completely close the client application) and reconnect, the messages are there and it works fine for another period of time.

Debuggin via network packet sniffer revealed that after almost exactly 100 minutes after connection and accessing the topic, our client stops sending the period "get" messages. It does however send hearbeat messages every 5 minutes from this point on - this seems to be clients (libraries) automatic feature. However, client side logging reveals that im actually still sending out requests for new messages and each time i keep getting code 2033 as a response, even if messages are actually there. Because of the timely fashion of this occurring every 100 minutes, we think it's some kind of a timeout, but we're unable to determine what timeout. After some searching i found this in the IBM's documentation: http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.ref.con.doc/q081860_.htm About disconnect interval being set to 100 minutes, but after contacting the MQ server administrators from the other company, I got assured that in fact they have this value set to 0, so this should not be the case. Also, according to the network sniffing, it looks like the client is stopping the Get messages rather than the server disconnecting us.

There is an even bigger puzzle. We tried soft disconnect of the queuemanager and reconnecting and re-accesing the topics, but it does not help, as if there are some static fields kept even with new instances of queuemanager. We need to completly shutdown the client program to be able to receive messages. And all this time, we don't get any other error messages except code 2033 (no new message).

Now for some code. This is used every time for connection/reconnection:

public void Connect()
{
    MQEnvironment.Hostname = connectionName;//please assume those are correctly filled values
    MQEnvironment.Port = port;
    MQEnvironment.Channel = channelName;
    queueManager = new MQQueueManager(QueueManagerName);
}

Next we access the topic.

public MQTopic AccessTopic(string topicName)
    {
        MQTopic topic = null;
        topic = queueManager.AccessTopic(topicName, null, MQC.MQSO_CREATE | MQC.MQSO_FAIL_IF_QUIESCING | MQC.MQSO_MANAGED | MQC.MQSO_DURABLE | MQC.MQSO_RESUME, null, "subNameXYZ");
        return topic;
    }

Next, we read the topic. All the functions are working with Try/Catch statemsnts, but i've cleaned them a bit to make it easier to look at. This is working in a loop, every 2 minutes.

public string ReadTopic(MQTopic topic)
    {
        string strReturn = "";
        if (topic != null)
        {
            try
            {
                queueMessage = new MQMessage();
                queueMessage.Format = MQC.MQFMT_STRING;
                queueGetMessageOptions = new MQGetMessageOptions();
                topic.Get(queueMessage, queueGetMessageOptions);
                strReturn = queueMessage.ReadString(queueMessage.MessageLength);
                queueMessage.ClearMessage();
            }
            catch (MQException exp)
            {
                //checking if code = 2033 "no new message"
            }
        }
        return strReturn;
    }

In addition, every loop, before accessing readtopic, we check if the connection is ok and if not, reconnect,like following:

public void CheckConnection()
{
    if (!queueManager.IsConnected)
    {
        queueManager.Disconnect();
        queueManager.Close();
        Connect();
    }
}

So, in short: The question is what can cause our connection to stop receiving messages from the topic after almost exactly 100 minutes every time, even though there are no error messages, and new messages are published in this topic after those 100 minutes? Side question: Why soft reconnection does not work, and to be able to access the messages we need to shut down the program completly?

Answer 1

There are almost no scenarios in MQ that might cause this behavior. It is possible for example for a browse cursor to not see newer, higher priority messages that arrive. Incomplete message groups can also return a 2033 despite non-zero queue depth. However your description does not support either of these scenarios as the cause.

However this part seems to indicate a bug in MQ classes:

Debuggin via network packet sniffer revealed that after almost exactly 100 minutes after connection and accessing the topic, our client stops sending the period "get" messages. It does however send hearbeat messages every 5 minutes from this point on - this seems to be clients (libraries) automatic feature. However, client side logging reveals that im actually still sending out requests for new messages and each time i keep getting code 2033 as a response, even if messages are actually there.

The classes cannot reliably return a 2033 unless they first ask the QMgr for messages. If your packet captures are complete (ie the network flows of interest did not traverse a thread or socket that wasn't being captured) then the behavior reported by the classes does not match the behavior actually performed. If you can reliably reproduce it under trace, IBM should be able to resolve it in a PMR.

Until that time, you may be forced to implement a work-around such as periodically restarting the app. You might also try creating a managed subscription to a pre-defined queue and changing the app to poll that. If the problem is isolated to the Topic object this would fix it without disturbing any other subscribers on that topic.