Thanks, Mark. Adding
CLIENTRECONNECTOPTIONS: ANY to the ibm.mq.additionalProperties in application.yaml seems to have worked. For others who might be searching I found these properties documented
here.
I did notice one behavior that I'm not certain about. Initially, both my clients connected to the first qmgr. Within a few seconds a balance request was logged on the console of the second qmgr and one instance of my application reconnected. This all went as expected, except that I saw the following two message logged repeatedly at the first qmgr's console.
03/28/22 15:51:41 - Process(212.27) User(mqm) Program(amqzlaa0)
Host(mqserver-uc-0) Installation(Installation1)
VRMF(9.2.0.4) QMgr(QC90)
Time(2022-03-28T15:51:41.299Z)
CommentInsert1(amqrmppa)
AMQ5540E: Application 'amqrmppa' did not supply a user ID and password
EXPLANATION:
The queue manager is configured to require a user ID and password, but none was
supplied.
ACTION:
Ensure that the application provides a valid user ID and password, or change
the value of CHCKCLNT to OPTIONAL on the AUTHINFO object specified by the
CONNAUTH attribute on the queue manager. For the change to take effect, you
must refresh the connection authentication configuration of the queue manager.
----- amqzfuca.c : 5089 -------------------------------------------------------
03/28/22 15:51:43 - Process(549.7) User(mqm) Program(amqrmppa)
Host(mqserver-uc-0) Installation(Installation1)
VRMF(9.2.0.4) QMgr(QC90)
Time(2022-03-28T15:51:43.302Z)
RemoteHost(172.19.0.1)
CommentInsert1(ccxOPT_NETWORK_ERROR)
CommentInsert2(ccxReceive)
AMQ9213E: A communications error for ccxReceive occurred.
EXPLANATION:
An unexpected error occurred in communications.
ACTION:
The return code from the ccxReceive call was 0 (X'0'). Record these values and
tell the systems administrator.
----- amqcccxa.c : 2590 -------------------------------------------------------
This went on for about a minute and then stopped. Both consumer client instances are connected and able to receive messages. What is the meaning of these errors? Application 'amqrmppa' is the channel pooling process from what I read. Are these errors normal, or is there something else I should do? We use LDAP for security and the clients supply a user ID and password when they log in. FWIW, I don't see these errors whenever our NodeJS clients rebalance.
Jim
------------------------------
Jim Creasman
------------------------------
Original Message:
Sent: Mon March 28, 2022 05:22 AM
From: Mark Taylor
Subject: Spring JMS and MQ application rebalancing with default MQ connection factory
- "DISPLAY CONN(*) WHERE(APPLTYPE EQ USER) CONNOPTS" will show the effective reconnect options in case the channel has explicitly overridden the app
- Don't forget that JMS "Connections" can result in >1 MQ connection; for rebalancing purposes they are tied together based on the generated CONNTAG value
- If further options are needed on the CF that are not explicitly listed as configurable, then you can either use a customizer method or use the "additionalProperties" map in the configuration
- Using debug logging on the Spring app will show the applied configuration for the CF to make sure your config is correctly set
------------------------------
Mark Taylor
Winchester
Original Message:
Sent: Fri March 25, 2022 05:22 PM
From: Jim Creasman
Subject: Spring JMS and MQ application rebalancing with default MQ connection factory
Is there a way to use the default MQ connection factory so that I can have application instances be rebalanced across a uniform cluster? The Spring JMS code is pretty simple in our case. I would prefer to not create a custom MQConnectionFactory just to rebalance.
Main class:
@EnableJms@SpringBootApplicationpublic class MyApplication { public static void main(final String[] args) { SpringApplication.run(MyApplication.class, args); }}
Message listener:
@Servicepublic class MessageService { @JmsListener(destination = "MQDEV.QUEUE.V1") public void listener(Message msg) { try { System.out.println(msg.getBody(String.class)); } catch (Exception e) { System.out.println("Failed!"); } }}
These are the relevant values from application.yaml:
spring: jms: pub-sub-domain: false ibm: mq: queue-manager: "*QM_ANY" ccdt-url: <my CCDT URL> user: <user> password: <pwd> application-name: "My Application" default-reconnect: YES
I was hopeful the default-reconnect property would do the trick, but I still see both connections remain on the same qmgr. If I run "dis apstatus(*) all" on either of the queue managers I see COUNT(2), but BALANCED(NOTAPPLIC) for this application. For our other (non-JMS) clients the value for balanced eventually gets to YES and I see the instances reconnect to different qmgrs.
I believe what I really need is to specify WMQConstants.WMQ_CLIENT_RECONNECT in the connection properties. This would allow these clients to connect to any queue manager and accept the reconnect request. Would that fix the issue? Is there a way to access the connection properties for the default MQ connection factory that is being used, or do I need to create a custom MQConnectionFactory as mentioned in this
post from StackOverflow? In a uniform cluster world it would be nice to have a property for this exposed. We are using version 2.6.3 of the mq-jms-spring-boot-starter package.
Thanks,
Jim
------------------------------
Jim Creasman
------------------------------