| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Multi instance QMGR |
« View previous topic :: View next topic » |
| Author |
Message
|
| JP1156 |
 Posted: Thu Mar 31, 2022 10:03 am Post subject: Multi instance QMGR |
 |
|
Newbie
Joined: 31 Mar 2022
Posts: 3
|
Installed IBM MQ 9.2.0.2 on Windows2019 as multi instance queue manager.
When the qmgr fails over node node B, the sender channel goes out of sequence and vice versa when failing back to node A the sender goes out of sequence.
Fairly new to multi instance qmgrs, hence is this expected behavior?
Thanks! |
|
| Back to top |
|
 |
| hughson |
| Posted: Thu Mar 31, 2022 6:25 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
It is not expected behaviour because the state of the channel should be stored on the shared discs used by the multi-instance queue manager. So the same state should be used when the queue manager fails over to node B.
Can you tell us a little more about your multi-instance queue manager setup please? We know you're on Windows 2019 from your question, but tell us about the disc technology and your addmqinf setup.
IBM Docs says "For multi-instance queue managers on Microsoft Windows, the networked storage must be accessed by the Common Internet File System (CIFS) protocol used by Microsoft Windows networks." This is the ONLY supported file system for multi-instance queue managers on Windows. Can you confirm this is what you are using?
Also, you should probably describe where the sender channel is too. The receiver channel I'm guessing, is what is on the multi-instance queue manager. Where is the sender.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Apr 01, 2022 3:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I guess this might have more to do with the MCAUserId on the channel and the permissions of said user. If you don't have the right permissions, you can't write to the scratchpad and the sequence number may / will get lost. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JP1156 |
| Posted: Fri Apr 01, 2022 6:51 am Post subject: |
|
|
Newbie
Joined: 31 Mar 2022
Posts: 3
|
| hughson wrote: |
It is not expected behaviour because the state of the channel should be stored on the shared discs used by the multi-instance queue manager. So the same state should be used when the queue manager fails over to node B.
Can you tell us a little more about your multi-instance queue manager setup please? We know you're on Windows 2019 from your question, but tell us about the disc technology and your addmqinf setup.
IBM Docs says "For multi-instance queue managers on Microsoft Windows, the networked storage must be accessed by the Common Internet File System (CIFS) protocol used by Microsoft Windows networks." This is the ONLY supported file system for multi-instance queue managers on Windows. Can you confirm this is what you are using?
Also, you should probably describe where the sender channel is too. The receiver channel I'm guessing, is what is on the multi-instance queue manager. Where is the sender.
Cheers,
Morag |
Hi Morag, appreciate the response, we're using SMB 3.0 file system with 'Continuous Availability' option on Windows which is supported.
output from dspmqinf:
QueueManager:
Name=HSDEVMGR
Directory=HSDEVMGR
Prefix=C:\ProgramData\IBM\MQ
DataPath=\\Ps01-vm02\11ibmmq\data\HSDEVMGR
InstallationName=Installation1
The sender is on the multi-instance qmgr and so is the requester going out to vendor.
Typically the sender will go out of sequence followed by the requester.
sender channel (sequence number 7 sent, 1 was expected)
requester (sequence 1 sent, 6 was expected)
Thanks!
John |
|
| Back to top |
|
|
| JP1156 |
| Posted: Fri Apr 01, 2022 10:28 am Post subject: |
|
|
Newbie
Joined: 31 Mar 2022
Posts: 3
|
Here's a sequence of events...
before failover from node 1 to node 2...
requester: CURSEQNO(1) LSTSEQNO(1)
sender: CURSEQNO(1) LSTSEQNO(1)
after failover to node2...
requester: CURSEQNO(1) LSTSEQNO(1)
sender: CURSEQNO(1) LSTSEQNO(1)
When message was sent:
requester: CURSEQNO(1) LSTSEQNO(1)
sender: CURSEQNO(2) LSTSEQNO(1)
Error on sender channel: message sequence 2 was sent, 1 was expected
Reset sender channel to 1, Sender channel in running state
Requester channel went from running to inactive.
Error on requester channel: 1 was sent, 2 was expected.
Reset requester channel to 1, requester channel in running state.
Since the sender and requester have a security exit, I am starting to think that might be the culprit. Security exits are identical and local to the server(s), wonder if they should be on the shared drive instead? |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
