I have a situation with a multi instance qmgr (IBM MQ v9.2.0.22) where the connecting application utilizing MCONNX connections from a jms client to the MQ Server is experiencing timeouts when the multi instance qmgr fails over to the secondary instance.  We are seeing that any connection that utilizes connection pooling is cycling through the connectionnamelist causing timeouts of the application.  I understand that this is normal behavior, a new connection is going to attempt to connect to the first in the list and when it times out after being unable to connect, it will move on to the next.  However, I need to find a solution to the application time out issue when it failsover.  Just Looking for suggestions or other options.  I have referred them to numerous sites regarding Application reconnect options and here is what they are using for their connection information.  

jms.server.connectionnamelist=<FQDN>(1414),<fqdn>(1415)
jms.server.channel=CLIENT.01.QMGRNAME
jms.server.queuemanager=QMGRNAME
jms.max.concurrent.connections=5
jms.client.pollingintervalms=500
jms.client.rescanintervalms=500
jms.server.failifquiesce=1
jms.server.clientreconnectoptions=Q_MGR 

They also utilize these settings to control their sessions:  

jdbc.unreturnedConnectionTimeout=1800
jdbc.maxConnectionAge=3600
jdbc.maxIdleTime=1800
jdbc.maxIdleTimeExcessConnections=900
jdbc.maxPoolSize=15
jdbc.maxStatements=50
jdbc.minPoolSize=5
jdbc.unreturnedConnectionTimeout=1800

They are not using a CCDT for this connection.  And only the part of the application that utilizes the connection pooling is having the issue with Multi Instance.  Anything utilizing a static connection fails over fine.  I am looking for options that will work with MIQM and will not cause the asynchronous handles to run rampant.

Any thoughts, suggestions or insights would be greatly appreciated.  

for reference, the MQ Server(primary and secondary) are running on windows and the application is running on AWS EKS instances.  

------------------------------
Deanna Pitcher County
------------------------------

Hi Deanna,

You did not disclose all of your JMS pooling properties, or else some are missing.

Look into the properties that tell you what to do if there is a broken connection in the pool. The usual response is to purge the whole pool.

I would also suggest that you might use a JSON CCDT with 2 entries for the MIQM qmgr. The difference with the one entry (2 hosts, port) vs 2 entries (2 qmgrs) would need to be tested to see which one gives you the best response time.

Furthermore set up your JMS program to cache the connection internally, but clear that cache in case of connection broken and other connection related exceptions;
best way is to request the cached connection. If the cache is present use it, if it is not present, create the cache entry.

Hope it helps

Hi Francois,

Thank you for your reply.  This helped quite a bit.  I will be following up with the App Developer to see if they left any properties out of what they sent me.  I feel like they have sent me everything they have configured, which is part of the problem.  Hence the strange loop we are in.  

I have been hinting to them about utilizing a CCDT file, but I had not thought about your suggestion for 2 entries as opposed to the single entry with the connectionnamelist.  I will definitely look into that and try it.  

I will also talk to the App Devs about caching the connection, but I feel like they have tried this in the past and it caused issues with the handle counts continually growing and not being released.  But I will have them look into this again as it might end up being the best option.  

Thank you again for your response.  I will let you know how it goes.  

If caching the connection leads to issues with the handle counts, then the developer doesn't correctly release the connection to the pool and there is a problem in the way error handling is done.

Remember on a request reply scenario the MDB needs (2*mdb instances) +1 connections. The max pool size should be calculated in consequence.

Hope that helps.