MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Use of CCDT servicer with IBM MQ and Native HA

    Posted Tue November 04, 2025 10:46 AM

    I have an IBM MQ uniform cluster consisting of two qmgrs.  Along with these we have a HTTP service that supplies the clients with the CCDT to use when connecting.  

    I'm currently looking into the modifications I will need to add Native HA to this configuration, specifically as it relates to the CCDT.  What I read is that when a failover occurs, or when the active/recovery groups change (as in a switchover), the CCDT must be updated with the new hostnames for the active group.  I'm wondering if there is a way to pre-enter this information so the process of switching is automated from the CCDT point of view.   In other words, when the active group changes is there a way to supply the CCDT info in advance such that they find the group and reconnect?

    Another solution is for our CCDT service to detect that a change has occurred and react by returning the updated CCDT.  Can the CCDT service request notification whenever a new active group comes online?  

    Thanks



    ------------------------------
    Jim Creasman
    Enterprise Modernization Architect
    Primerica
    Raleigh NC
    ------------------------------


  • 2.  RE: Use of CCDT servicer with IBM MQ and Native HA

    Posted Wed November 05, 2025 12:35 AM

    Hi Jim,

    Yes there is. The host/port combo in the Json CCDT is an array. So for the same queue manager you can enter 6 values (3 primaries and 3 secondaries(DR)... Make sure you enter the preferred values first, this minimizes the re-connection time as each connection is tested in sequence.

    Hope it helps



    ------------------------------
    Francois Brandelik
    ------------------------------

    Original Message


  • 3.  RE: Use of CCDT servicer with IBM MQ and Native HA

    Posted Wed November 05, 2025 01:53 PM

    Thanks, Francois.  I thought it must work something like that.  This is what I have today for the QM_ANY entry in the CCDT (without Native HA).


     And this is how the CCDT entry should look with Native HA.  Is that correct?  The order listed means a client would first try to connect to the qmgrs in UC1 before moving on to UC2 and last UC3.  If a client attempts to connect to a replica, does it allow the connection and then request the client move to the active?  Or, does the replica simply refuse the connection request and make it try the next one in the list?



    ------------------------------
    Jim Creasman
    Enterprise Modernization Architect
    Primerica
    Raleigh NC
    ------------------------------

    Original Message


  • 4.  RE: Use of CCDT servicer with IBM MQ and Native HA

    Posted Wed November 05, 2025 02:02 PM

    Hi Jim,

    Sure looks like it. But remember you also need an entry for each individual queue manager...

    Usually I don't have a single entry for QM_ANY. In your case I'd have 2 entries with QM_ANY and one for each of the qmgrs by name...

    Hope it helps



    ------------------------------
    Francois Brandelik
    ------------------------------

    Original Message


  • 5.  RE: Use of CCDT servicer with IBM MQ and Native HA

    Posted Wed November 05, 2025 02:12 PM

    Right about the entries for each individual qmgr.  I left those out for simplicity.  

    Regarding multiple QM_ANY entries (one per connection) vs single QM_ANY with multiple connection entries, is there any advantage to either approach?  I've seen both ways implemented.  Curious if it makes a difference.



    ------------------------------
    Jim Creasman
    Enterprise Modernization Architect
    Primerica
    Raleigh NC
    ------------------------------

    Original Message


  • 6.  RE: Use of CCDT servicer with IBM MQ and Native HA

    Posted Wed November 05, 2025 02:19 PM
    Edited by Francois Brandelik Wed November 05, 2025 02:20 PM

    The difference is in the distribution of the connections.

    If you set an affinity of 50/50 you will distribute the initial connections in a round robin way.

    If you have both QM_ANY under one entry, the first host port tuple that works will always be chosen...



    ------------------------------
    Francois Brandelik
    ------------------------------

    Original Message


  • 7.  RE: Use of CCDT servicer with IBM MQ and Native HA

    Posted Wed November 05, 2025 04:06 PM

    I'm still not sure I see the difference in the two approaches.  For example, I could use a single QM_ANY entry:

    {
    "name": "APP.SVRCONN",
    "type": "clientConnection",
    "clientConnection": {
        "connection": [
            {
                "host": "mq.uc1host.com",
                "port": 11414
            },
            {
                "host": "mq.uc1host.com",
                "port": 21414
            }
        ],
        "queueManager": "QM_ANY"
    }
}

    Or, I could have two entries like this:

    {
    "name": "APP.SVRCONN",
    "type": "clientConnection",
    "clientConnection": {
        "connection": [
            {
                "host": "mq.uc1host.com",
                "port": 11414
            }
        ],
        "queueManager": "QM_ANY"
    }
},{
    "name": "APP.SVRCONN",
    "type": "clientConnection",
    "clientConnection": {
        "connection": [
            {
                "host": "mq.uc1host.com",
                "port": 21414
            }
        ],
        "queueManager": "QM_ANY"
    }
}

    My observation is that the client will still first try to connect to the entry at port 11414 before trying 21414 (b/c it's first in the order).  Once the connection is made the qmgr will tell the client to connect to a different qmgr (by name) if the connections are not balanced.  This seems to be true with either approach.  All things being equal, I prefer the first as it's more compact.

    I don't recall explicitly set the connection affinity.  Is this something I should be doing, or is the default 50/50?

    Thanks for your help,

    Jim



    ------------------------------
    Jim Creasman
    Enterprise Modernization Architect
    Primerica
    Raleigh NC
    ------------------------------

    Original Message


  • 8.  RE: Use of CCDT servicer with IBM MQ and Native HA

    Posted Wed November 05, 2025 04:14 PM
    Edited by Francois Brandelik Thu November 06, 2025 04:15 AM

    Sorry it's client Weight not affinity...

    You are missing the client weight entry for the client connection in the second scenario where you have 2 QM_ANY defined.

    Say you have the client weight entry and you have 20 connections being made.

    With the round robin you'd have roughly 10 to QM1 and 10 to QM2 before reallocation by the UC.

    Without the client weight entry all connections go to the first qmgr and get then reallocated by the UC...

    Check for the full syntax of the Json CCDT. I believe you have to use the client weight entry to get the round robin behavior...

    See an example:

    { 	"channel": [
		{
			"compression": 
			{
				"header": ["none"],
				"message": ["none"]
			},
			"connectionManagement": 
			{
				"sharingConversations": 10,
				<strong>
                "clientWeight": 5,
				"affinity": "none",
				</strong>
                "defaultReconnect": "yes",
				"heartbeatInterval": 600
			},
			"exits": 
			{
				"security": 
				{
					"name":"MQ94\\mqccred(ChlExit)",
					"userData": "ERROR"
				}
			},
			"general": 
			{ 
				"description": "channel for FR1",
				"maximumMessageLength": 4194304 
			},
			"name": "FJ",
			"clientConnection": 
			{
				"connection": [
					{
						"host": "localhost",
						"port": 1414	
					}
				],
				"queueManager": "QM_ANY"
			},
			"transmissionSecurity":
			{
				"cipherSpecification": "",
				"certificateLabel": "",
				"certificatePeerName": ""
			},
			"type": "clientConnection"
			
		}
      ]
}



    ------------------------------
    Francois Brandelik
    ------------------------------

    Original Message


Related Content