MQ

 View Only
Expand all | Collapse all

Reconnect mechanism in IBM.XMS library -> https://www.nuget.org/packages/IBMXMSDotnetClient

  • 1.  Reconnect mechanism in IBM.XMS library -> https://www.nuget.org/packages/IBMXMSDotnetClient

    Posted 5 days ago
    Edited by Lorraine Rizzuto 3 days ago

    Greetings,

    I've been having torrid time getting the IBM.XMS library (managed nuget) to behave due to various bugs. However I noticed a significant improvement when version 9.4.0 was released which is .net 8 only. The reconnect mechanism seemed to have improved so I thought all my problems where solved. 

    In terms of client reconnect mechanism I simply want the same functionality as is in the unmanaged .net framework version of the same/similar library. I mainly want the clients to reconnect in situations that are known to happen such as:

    • Failover between sites (this seems to be working in version 9.4.0)
    • REFRESH SECURITY issued on QManager side.

    I have a bunch of SOAP services that are using the .net unmanaged version (full blown IBM client installed on Windows servers). They rarely have problems and seem to be able to reconnect most of the time, at least in the cases mentioned above. I basically copy pasted the same code into the .net 8 version of my new services but as I mentioned it hasn't been working properly. The legacy stuff is able to reconnect but the brand new .net 8 clients running on Linux in Kubernetes can't reconnect.

    My .net 8 clients are all using TLS connection to the QManager and now there was some maintainance on the QManager where a certificate was added to the keystore and the REFRESH SECURITY command was issued. The CA certificate my client was using remained the same so in my mind the IBM.XMS library should have reconnected automatically (just like the legacy SOAP services). However as soon as the command was issued on the server side this happend in the client:

    IBM.XMS.XMSException: MQ delivered an asynchronous event with completion code 2, and reason 2202. XMSWMQ2014.explanation XMSWMQ2014.useraction

    Consequently the health check failed in my worker service (which determines if the MQ connection is alive by trying to create a session on the connection..):

    IBM.WMQ.MQException: MQRC_CONNECTION_QUIESCING at void IBM.WMQ.MQBase.throwNewMQException(int cc, int rc) at void IBM.WMQ.MQFAP.NmqiConnect(string name, NmqiConnectOptions pNmqiConnectOpts, MQConnectOptions cno, Hconn remoteParentHconn, Phconn pHconn, out int compCode, out int reason, ManagedHconn rcnHconn) x 2 at new IBM.XMS.Client.WMQ.WmqSession(WmqConnection connection, AcknowledgeMode ackMode, XmsPropertyContext properties) at ISession IBM.XMS.Client.Impl.XmsConnectionImpl.CreateSession(bool transacted, AcknowledgeMode ackMode) at bool XXX.Libraries.IBMMQClient.MessagingClient.get_IsConnected()


    To my understanding this means that the reconnect mechanism in the IBM.XMS client library has given up. Shouldn't the reconnection mechanism in the library handle such cases? Are there any connection properties I can set so that the reconnect mechanism behaves better and handles this case? I really do not want to roll my own reconnect mechanism but at the moment that is the only viable option. 

    IBMXMSDotnetClient version I'm using is 9.4.1

    ------------------------------
    Bjarki Björgúlfsson
    ------------------------------