在关闭和断开IBM MQ.NET客户端上设置超时

Question

Is it possible to set timeout period for the code below:

private MQQueueManager queueManager;
private MQQueue queue;

   ...
queue.Close();
queueManager.Disconnect();

The reason is that sometimes the connection get stuck trying to close. The thread blocked on Close() or Disconnect().

Update

The client uses managed client, CCDT file, cluster queue manager and other features that might result in different settings.

Please provide code sample.

Can we change the timeout setting using similar method via APIs like below:

    int openOptions = Set possible settings here

    var properties = new Hashtable
    {
          Set possible settings here
    };

    _queueManager = new MQQueueManager(_queueManagerName, properties);
    _queue = _queueManager.AccessQueue(QUEUE_NAME, openOptions);

Answer 1

The way the MQ client and MQ server decide to TIMEOUT a connection is based on the negotiated Heart Beat ( HBINT ) value for the running SVRCONN channel. The negotiated HBINT is always the highest value negotiated between the SVRCONN and the client application.

Note: SVRCONN HBINT has a default value of 300 .

The TIMEOUT is determined in one of two ways:

1. If the negotiated HBINT is less than 60 the TIMEOUT is 2x HBINT .
2. If the negotiated HBINT is greater than or equal to 60 the TIMEOUT is HBINT + 60.

---

Specific to the area of .NET clients related to HBINT :

APAR IT26614 corrects the following three issues:

1. In either Unmanaged or Managed mode it is documented that if you are not using a CCDT the HBINT will use the value of the SVRCONN channel. In reality if not using a CCDT the HBINT on the client side defaults to 300 so this is the lowest HBINT you will see.

2. Specific to Managed .NET the client side HBINT cannot be lower than the SVRCONN HBINT the connection will fail with a 2059. This problem impacts both with or without CCDT.

   • with a CCDT you are unable to set the CLNTCONN HBINT to a value less than the SVRCONN HBINT
   • without a CCDT you will be impacted if the SVRCONN HBINT is set to 301 or higher

3. Specific to Managed .NET the client side receive timeout was being calculated in milliseconds not seconds. In this case the defect has been present according to IBM for a long time, but did not present itself until APAR IT16167: Managed .NET client application does not send heartbeat request to queue manager was introduced in 8.0.0.10 and 9.0.0.4 (IBM also confirmed this is present in GA 9.1.0.0). The reason it was not previously a problem was that Managed .NET was never initiating the Heart Beat, the queue manager would always send the Heart Beat at HBINT + 5 seconds and the .NET client would respond. Once this was corrected, the miscalculation of the receive timeout presented itself.

 The fix is targeted for delivery in the following PTFs: Version Maintenance Level v8.0 8.0.0.13 v9.0 LTS 9.0.0.7 v9.1 CD 9.1.3 v9.1 LTS 9.1.0.3 

As of July 12th 2019 only 9.0.0.7 and 9.1.3 have been released and can be downloaded from the following locations:

• 9.0.0.7 MQC9: IBM MQ V9 Clients
• 9.1.3 MQC91: IBM MQC91: IBM MQ Clients

---

Unless you are using a version of the amqmdnet.dll which includes the above APAR or you ask IBM to provide you with a IFIX for any lower version, the only way to accomplish a lower than 300 HBINT would require the SVRCONN HBINT to be set to a lower value in combination with the client using a CCDT with the CLNTCONN HBINT set to a lower value. Based on unmanaged or Managed .NET you have two options:

1. With unmanaged .NET you can set the CLNTCONN HBINT to 1 and allow the client to to always negotiate up to the SVRCONN HBINT value. You would then need the MQ admin to set the SVRCONN HBINT to the desired value.
2. With Managed .NET you would need the MQ admin to set the SVRCONN HBINT to the desired value, and you would then need to set the CCDT CLNTCONN HBINT to the same value as the SVRCONN HBINT .

---

If you are using a version of the amqmdnet.dll which includes the above APAR or you ask IBM to provide you with a IFIX for any lower version the following will be how things work:

1. If not using a CCDT the client side will use the equivalent of HBINT(1) and will negotiate up to the SVRCONN value.
2. If using a CCDT the CLNTCONN can have the HBINT set to 1 which would result in the same behavior as above when not using a CCDT, the HBINT will negotiate up to the SVRCONN value.

No matter if using a CCDT with CLNTCONN HBINT set to 1 or not using a CCDT where client side will use HBINT(1) , you will need to ask the MQ admin to set the SVRCONN HBINT to a lower value to accomplish a shorter TIMEOUT.

---

Example of setting HBINT on the CCDT CLNTCONN channel:

DEFINE CHL(CLIENT_CHL) CHLTYPE(CLNTCONN) CONNAME('1.2.3.4(9999)') QMNAME(ABC) HBINT(1)