CODEWITHSUNDEEP
c#ibm-mq
Dirty Developer
Dirty Developer

Reputation: 562

MQ Client is taking much time to understand that MQ queue manager is down

try
    {
        MQManager = new MQQueueManager(QueueManager);
        try
        {
            MQRequestQueue = MQManager.AccessQueue(QueueName, MQC.MQOO_INPUT_AS_Q_DEF + MQC.MQOO_FAIL_IF_QUIESCING);

            return true;
        }
        catch (IBM.WMQ.MQException exIBM)
        {
            CloseConnection();
            ErrorCode = exIBM.Reason;
            ErrorDescription = exIBM.Message;
                            }
    }
    catch (IBM.WMQ.MQException exIBM)
    {
        CloseConnection();
        ErrorCode = exIBM.Reason;
        ErrorDescription = exIBM.Message;

I am using the above c# code to connect to the MQ using MQseries dll provided by WebsphereMQ. When QueueManager is down it is taking 20-30 seconds till I get the exception and I can see everything has been just stopped at this code.

Is it expected behaviour of MQ client-server communication? If not ,How can I detect if queuemanager is down so that I can hit next available queuemanager? Is there any timeout property?

Upvotes: 1

Views: 1396

Answers (3)

Dirty Developer
Dirty Developer

Reputation: 562

MQ Client is taking time to understand MQ queue is down, because of TCP connection time out. MQ client, if installed on Windows server, wait for some fix amount of time based on the TCP timeout settings of the Windows OS.

If you want to handle TCP timeout for MQclient, you can do it via mqclient.ini located at your installed MQ location i.e. C:/../IBM/Webshperemq

http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.con.doc/q016840_.htm

Upvotes: 0

Morag Hughson
Morag Hughson

Reputation: 7515

When you are running over the client-server communication as you state that you are, then there is a network involved. The detection time of your application of when the queue manager goes unavailable will depend on what the application was doing at the time and how the queue manager was ended.

If the queue manager was quiesced, and the application was using the queue manager connection at the time then you should get immediate notification. Similarly, if you have a connection exception handler then even if your application was not using the queue manager connection at the time, the exception handler counts as if it was, and you should get immediate notification. The snippet of code you provide suggests that perhaps you are hinting that you are in a waiting get when the queue manager is taken down?

If the queue manager was brought down more harshly than a quiesce, then you may have to rely on network timeouts to detect that the queue manager is no longer at the other end of the socket and this is where your delay will be seen.

Could you indicate in your question how the queue manager was ended and also whether you have an exception handler or whether your application was actually using the connection at the time the queue manager went down.

Can you also update your question with IBM MQ versions and the details of your SVRCONN channel, specifically SHARECNV and HBINT.

Upvotes: 2

Shashi
Shashi

Reputation: 15263

Since you have not give complete code, it's not clear from your code as to what type connection, bindings or client, you are using. Does your application connect to the queue manager running on the same machine(as your application) or a different machine. Have you initialized MQEnvironment class in your code?

If it's bindings connection, i.e. your application connects using shared memory to a queue manager running on the same machine, then an exception should be thrown immediately.

If your application connects to a queue manager running on a different machine, then network delays comes into picture. It's also possible that host name resolution is taking time. So you need to check your network.

I guess we need more information about your application. Based on that I may be able to offer assistance further.

Upvotes: 1

Related Questions