| Author |
Message
|
| pmarie |
 Posted: Wed Feb 28, 2018 7:39 am Post subject: CLUSSDR channels do not auto start |
 |
|
Novice
Joined: 04 Apr 2002
Posts: 23
|
I created an MQ configuration on two servers with the following features:
- A first queue manager "QM1" has an active instance on server 1 and a standbye one on server 2.
- A second queue manager "QM2" has an active instance on server 2 and a standbye one on server 1.
- The two queue managers are part of a common cluster "MQCLUST" and both are full repositories for the cluster.
- The NFS file system used by the two queue managers is hosted by a third server.
I defined cluster channels the following way:
For QM1:
define channel(MQCLUST.QM1) chltype(CLUSRCVR) trptype(TCP) conname('192.168.179.136(1415), 192.168.179.137(1415)') cluster(MQCLUST)
define channel(MQCLUST.QM2) chltype(CLUSSDR) trptype(TCP) conname('192.168.179.137(1416), 192.168.179.136(1416)') cluster(MQCLUST)
For QM2:
define channel(MQCLUST.QM2) chltype(CLUSRCVR) trptype(TCP) conname('192.168.179.137(1416), 192.168.179.136(1416)') cluster(MQCLUST)
define channel(MQCLUST.QM1) chltype(CLUSSDR) trptype(TCP) conname('192.168.179.136(1415), 192.168.179.137(1415)') cluster(MQCLUST)
This configuration works file, except that:
- When starting the two queue managers, the cluster sender channels do not start automatically (it has to be started manually).
- When one of the queue managers fails over to the other server, the cluster sender channel of the failed over QM does not start automatically either (it has to be started manually).
From the documentation, my understanding is that the cluster sender channels should start automatically.
Any idea about what to do to have them start automatically? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Feb 28, 2018 7:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
What do the queue manager logs have to say about what's happening?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pmarie |
| Posted: Wed Feb 28, 2018 12:19 pm Post subject: |
|
|
Novice
Joined: 04 Apr 2002
Posts: 23
|
Nothing about an attempt to start the cluster sender channel.
The only messages with some relation with channels are:
AMQ5022: The channel initiator has started. ProcessId(32847)
The channel initiator process has started.
AMQ8024: IBM MQ channel initiator started.
The channel initiator for queue SYSTEM.CHANNEL.INITQ has been started.
They show up both when starting the queue manager and when failing it over to the other instance. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 28, 2018 12:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
So:
- all you do to start the channels is a START CHANNEL command?
- If you send a message to a cluster queue hosted on the other queue it sits in the SCTQ?
- What OS is this?
- What MQ version is this?
Consider (for experimental purposes) setting up a non-clustered sender/receiver pair between QM1 & QM2; see if that auto starts when a message tries to traverse it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pmarie |
| Posted: Thu Mar 01, 2018 12:56 am Post subject: |
|
|
Novice
Joined: 04 Apr 2002
Posts: 23
|
Hi Vitor,
It works as expected now (the channels do start automatically when needed). I did many things to repair it and do not know exactly which one actually fixed the issue:
- I refreshed the cluster on the two queue managers:
ALTER QMGR REPOS('')
REFRESH CLUSTER(MQCLUST) REPOS(YES)
ALTER QMGR REPOS(MQCLUST)
- I removed all the messages from the 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' queues of the two queue managers.
- I rebooted the two servers hosting the queue managers.
- I put some messages into a cluster queue using 'amqsput'.
The system is Linux RH 7.2 64-bit and the level of MQ is 9.0.0.2.
Thank you for your help!
Patrick |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 01, 2018 4:14 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| pmarie wrote: |
| I did many things to repair it and do not know exactly which one actually fixed the issue |
Too bad you don't know exactly what fixed this. A missed opportunity.
Next time you attempt to diagnose and fix something, try only ONE thing and document what you tried and the result. Repeat. Repeat until the issue is resolved. Then you can share your knowledge with others here ans elsewhere.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Mar 09, 2018 4:18 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| pmarie wrote: |
| Nothing about an attempt to start the cluster sender channel. |
Then it is reasonable to deduce that no attempt was made to start the cluster sender channel.
A cluster sender channel will start when a message is added to the SCTQ or whatever your CTQ is called.
Did one of your apps add a message? If not, then this might explain why the qmgr / channel initiator did not try to start the channel.
It's my best guess.  |
|
| Back to top |
|
|
|
|
