In a point to point MQ setup, we have sender one side and receiver at other side of the qmgr . between the QMGR’s there will be network .
QM1 –> QM2
QM1 (Local)
QM2 (Remote)
QM1 (Local)
QM2 (Remote)
Transmission Queue
MCA
Channel Retry
Message Flow
Adoption
Channel Network
MCA
recv()
If a channel fails, for example a communications error, there is no guarantee that both ends of the channel will detect the failure at the same time. Often the sending end of the channel detects the failure first since it is the end trying to send messages down the socket. What will happen therefore is that the sender will try to reconnect to the target Queue Manager. When the connection comes into the target machine the Queue Manager sees that it already has a channel running with that name and from that location. Consequently the new connection is rejected.
Sender side channel will be re-tried based on retry interval and after couple of retry interval the channel will go in to long re-try interval and will be never successfully connect .Due to the default value of AdoptNewMCA is No for the QMGR. to fix this permanently use AdoptNewMCA
By configuring AdoptNewMCA you can tell the Queue Manager that if a new connection arrives and there is already a channel with that name running from the same network address and from the same Queue Manager then the existing channel should be ended and replaced with this new instance. In other words, the channel instance should be ‘adopted’ by the new connection
The various configuration parameters in the channels stanza of QM.INI or equivalent (or on z/OS use ALTER QMGR) allow the behaviour of Adopt to be changed slightly. Set the list of channel types which may be adopted in this manner to turn on adoption
If IBM MQ receives a request to start a channel, but finds that an instance of the channel is already running, in some cases the existing channel instance must be stopped before the new one can start. The AdoptNewMCA attribute allows you to control which types of channels can be ended in this way. If you specify the AdoptNewMCA attribute for a particular channel type, but the new channel fails to start because a matching channel instance is already running:
- The new channel tries to stop the previous one by requesting it to end.
- If the previous channel server does not respond to this request by the time the AdoptNewMCATimeout wait interval expires, the thread or process for the previous channel server is ended.
- If the previous channel server has not ended after step 2, and after the AdoptNewMCATimeout wait interval expires for a second time, IBM MQ ends the channel with a CHANNEL IN USE error.
The AdoptNewMCA functionality applies to server, sender, receiver, and cluster-receiver channels. In the case of a sender or server channel, only one instance of a channel with a particular name can be running in the receiving queue manager. In the case of a receiver or cluster-receiver channel, multiple instances of a channel with a particular name might be running in the receiving queue manager, but only one instance can run at any one time from a particular remote queue manager. Note: AdoptNewMCA is not supported on requester or server-connection channels.
– AdoptNewMCA=SVR,SDR,RCVR,CLUSRCVR,ALL,FASTPATH
– ALTER QMGR ADOPTMCA(ALL/NO) (on z/OS)
Set the wait interval between ending the ‘adopted’ channel nicely and ending it immediate.
Distributed
QM.INI – AdoptNewMCA, AdoptNewMCATimeout, AdoptNewMCACheck
z/OS
ALTER QMGR ADOPTMCA(ALL) ADOPTCHK(ALL)
If a channel fails, for example a communications error, there is no guarantee that both ends of the channel will detect the failure at the same time. Often the sending end of the channel detects the failure first since it is the end trying to send messages down the socket. What will happen therefore is that the sender will try to reconnect to the target Queue Manager. When the connection comes into the target machine the Queue Manager sees that it already has a channel running with that name and from that location. Consequently the new connection is rejected.
– AdoptNewMCATimeout=60
Clearly the channel name must match but additionally you can specify that the network
address must be the same and also the remote Queue Manager name. This prevents a rogue connection from a different machine on the network from adopting already running channels. Set which attributes must match between the Adopted and new connections.
– AdoptNewMCACheck=QM,ADDRESS,NAME,ALL
– ALTER QMGR ADOPTCHK(NONE/QMNAME/NETADDR/ALL) (on z/OS)
The type of checking required when enabling the AdoptNewMCA attribute. If possible, perform full checking to protect your channels from being shut down, inadvertently or maliciously. At the very least, check that the channel names match.
Specify one or more of the following values, separated by commas or blanks in the case of QM, NAME, or ALL:
The default is AdoptNewMCACheck=NAME,ADDRESS,QM.