Hi Jim,
Just looking at Question 1 in this reply. The best-practice for using clients that work with transactions is the default. The default is to only ask a client to rebalance when it is NOT in the middle of a transaction. This seems fairly sensible to me.
However, if you want to change this default setting and go back to the behaviour in V9.2 whereby the client could be asked to rebalance even while it is in the middle of a transaction, then you can set up your mqclient.ini file thus:-
ApplicationDefaults:
Type=Simple
BalanceTimeout=Never
BalanceOptions=IgnTrans
It is necessary to supply all three of these attributes even though we only want to change the third one. If you want different values for the first two, go ahead and change them, but it's the third attribute that affects the transaction behaviour.
I too am a little surprised by the output showing MOVABLE(NO)
. It should be fairly easy to test whether your clients are told to move when they finish a transaction. One easy way to test is to just to SUSPEND one of the QMGRs from the CLUSTER, and watch what happens to the client applications. Then once you have seen enough, RESUME the suspended QMGR again.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website:
https://www.mqgem.com------------------------------
Original Message:
Sent: Wed May 03, 2023 05:54 PM
From: Jim Creasman
Subject: Application balancing in IBM 9.3 uniform cluster
We recently upgraded our MQ servers from 9.2 to 9.3. Since then we've noticed issues with keeping the client applications balanced across the cluster. Before 9.3 this was not an issue. We probably need to tweak some of the options, either at the qmgr, client or both. I've been reviewing the latest IBM documentation around application balancing and have a few questions about some of the newer states/options.
First, some background:
-- We have a two-node uniform cluster, each running a single qmgr.
-- Clients use a CCDT to connect.
-- Suspect clients are all MQ consumers.
-- Four instances of each client are running.
-- After the initial server restart the DIS APSTATUS command shows all instances of each client are balanced (i.e., 2 connected to each qmgr).
Questions 1
Running DIS APSTATUS('app-name') type(local)
shows below output:. I'm concerned that it has MOVABLE(NO). From the docs, the reason is INTRANS, meaning that it's inside a transaction. This client is using transactions. At what point does this client become "movable"? The docs indicate there are parameters that can be set to allow the qmgr to preempt the INTRANS state to maintain the balance. What is the best practice for this? The code is written to respond to rollbacks, so having one occur due to a rebalance is acceptable.
AMQ8932I: Display application status details.
APPLNAME(app-name)
CONNS(2) IMMREASN(INTRANS)
IMMCOUNT(0) IMMDATE( )
IMMTIME( ) MOVABLE(NO)
TYPE(LOCAL) BALTYPE(SIMPLE)
BALOPTS(NONE) BALTMOUT(10)
AMQ8932I: Display application status details.
APPLNAME(app-name)
CONNS(2) IMMREASN(INTRANS)
IMMCOUNT(0) IMMDATE( )
IMMTIME( ) MOVABLE(NO)
TYPE(LOCAL) BALTYPE(SIMPLE)
BALOPTS(NONE) BALTMOUT(10)
Questions 2
One of our clients showed as balanced right after the qmgrs were restarted, but a few minutes later all four instances had reconnected to one of the qmgrs. The IMMREASN had changed to NOREDIRECT. This is also a new state with 9.3, and indicates the client has informed the qmgr it cannot process redirect hints. It is using the CCDT, so what else could cause this change?
Thanks,
Jim
------------------------------
Jim Creasman
------------------------------