Home/ Questions/Q 837067
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T05:05:09+00:00

I can’t reconnect to MQQueueManager after a while as an exception (reason code 2059

  • 0

I can’t reconnect to MQQueueManager after a while as an exception (reason code 2059 – MQRC_Q_MGR_NOT_AVAILABLE) is thrown when I’m constructing new object of MQQueueManager. My client app is written in .NET/C# and I’m running it on Win2003.

However I can connect to QM after I have restarted my client app. This would indicate that some state is incorrect in QM libraries? How can I reset the state in code so that I could reconnect to QM? Is there a way to reset/disconnect all active TCP connections to QM from client app code?

My connection code:

    Hashtable properties = new Hashtable();
    properties.Add( MQC.HOST_NAME_PROPERTY, Host );
    properties.Add( MQC.PORT_PROPERTY, Port );
    properties.Add( MQC.USER_ID_PROPERTY, UserId );
    properties.Add( MQC.PASSWORD_PROPERTY, Password );
    properties.Add( MQC.CHANNEL_PROPERTY, ChannelName );
    properties.Add( MQC.TRANSPORT_PROPERTY, TransportType );
    // Following line throws an exception randomly
    MQQueueManager queueManager = new MQQueueManager( qmName, properties );

Stack trace:

    Source: amqmdnet
    CompletionCode: 2
    ReasonCode: 2059
    Reason: 2059
    Stack Trace:
     at IBM.WMQ.MQBase.throwNewMQException()
     at IBM.WMQ.MQQueueManager.Connect(String queueManagerName)
     at IBM.WMQ.MQQueueManager..ctor(String qmName, Hashtable properties)
     at WebSphereMQOutboundAdapter.WebSphereMQOutbound.ConnectToWebSphereMQ()
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Connections are per-thread so if you are attempting to create a new connection while the previous QMgr object is still instantiated, you would get this. If you close the previous connection and destroy the object before creating a new object you should be OK. Since queues and other WMQ objects depend on a connection handle these will also need to be destroyed and then reinstantiated after the new connection is made.

    There are of course a few other explanations for this behavior but these are much less likely. For example, it is possible that a channel exit or (in WMQ v7) configuration could be limiting the number of simultaneous connections from a given IP address. When a connection is severed rather than closed, the channel agent holding the connection on the QMgr side has to time out before the QMgr sees the connection as closed. If connection limiting is in place, these “ghost” connections reduce the available pool. But as I said, this is far less common than programs not cleaning up old objects prior to a reconnect attempt.

    There is also the possibility that this is a bug. To reduce that possibility, and for a variety of other reasons such as WMQ v6 going end of life next year, I’d recommend use of WMQ v7.0.1.2 for this project, at both the client and server side. In general, you can use v7.0.1.2 client with a v6.0.x server as long as you stick to v6 functionality. Among other things, .Net code is better integrated in v7 and the Cat-3 SupportPacs are now included in the base install media rather than a separate download.

    • 0