Author |
Message
|
jfecq |
Posted: Thu Sep 27, 2012 11:00 pm Post subject: remote queue switchover loses messages |
|
|
Apprentice
Joined: 24 Sep 2012 Posts: 36
|
Hi, I am using MQ 7.0.1.3.
I have a sender-receiver channel, with a remote queue definition on Machine A that mapped to local queue in B/C. The sender channel connection name is machineB(1414),machineC(1414)
Lets say A connects to B initially. If I shut down B,
1) A's sender channel will not immediately detects B is down. I have to send in messages before A will know the connection is broken and then try to connect to C.
2) I observed that when I send in few messages, first 2 messages will be lost. They are not in the transmission queue.
3) After A connects to C, then the remaining messages are sent to C.
Can some experts advised on this? Thanks! |
|
Back to top |
|
 |
exerk |
Posted: Fri Sep 28, 2012 12:10 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
So, what you appear to have is a Multi-Instance (MI) queue manager, and you are sure that two messages are 'lost'. WMQ doesn't lose messages but it will discard them if set up to do so, therefore, the questions are, what are the settings on the SDR channel, e.g. NPMSPEED, and is there a Dead-Letter Queue (DLQ) on the receiving queue manager? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
jfecq |
Posted: Fri Sep 28, 2012 1:33 am Post subject: |
|
|
Apprentice
Joined: 24 Sep 2012 Posts: 36
|
I didn't setup as MI. Rather I create similar queue manager and queue name on B and C. I know this may be wrong but I was just trying out the channel connection name initially.
NPMSPEED is FAST. There is DQL on B and C. But to begin with, not all messages are inside the transmission queue.
Then I tried to change the queue to persistent. Similarly, but now 1 message instead of 2 didn't go into the transmission queue. |
|
Back to top |
|
 |
exerk |
Posted: Fri Sep 28, 2012 1:42 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
jfecq wrote: |
I didn't setup as MI. Rather I create similar queue manager and queue name on B and C. |
This is very bad practice - it is not a good idea to have two discrete queue managers of the same name within your network (stand-by queue managers excepted, but that's a different story).
jfecq wrote: |
I know this may be wrong but I was just trying out the channel connection name initially. |
Very wrong, and likely to lead you down a path of despair. You're using a method intended for MI queue managers, not discrete and separate queue managers.
jfecq wrote: |
NPMSPEED is FAST. There is DQL on B and C. |
Read the manual in regard to what happens with non-persistent messages in regards to NPMSPEED(FAST) channels.
jfecq wrote: |
But to begin with, not all messages are inside the transmission queue. |
Please qualify this statement - messages are either in an application buffer, a message buffer, or on a queue.
jfecq wrote: |
Then I tried to change the queue to persistent. Similarly, but now 1 message instead of 2 didn't go into the transmission queue. |
Which queue? The XMITQ or the QREMOTE? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
jfecq |
Posted: Fri Sep 28, 2012 1:49 am Post subject: |
|
|
Apprentice
Joined: 24 Sep 2012 Posts: 36
|
jfecq wrote: |
I didn't setup as MI. Rather I create similar queue manager and queue name on B and C. |
This is very bad practice - it is not a good idea to have two discrete queue managers of the same name within your network (stand-by queue managers excepted, but that's a different story).
My intention is just to test out whether I have used the correct connection names in the channel. No intention to use 2 discrete qm with the same name.
jfecq wrote: |
But to begin with, not all messages are inside the transmission queue. |
Please qualify this statement - messages are either in an application buffer, a message buffer, or on a queue.
What I mean is messages did not end up in receiving queue manager DLQ. Because not all messages were at the transmission queue to begin with.
jfecq wrote: |
Then I tried to change the queue to persistent. Similarly, but now 1 message instead of 2 didn't go into the transmission queue. |
Which queue? The XMITQ or the QREMOTE?[/quote]
Local queue at receiving queue manager to persistent.
I will try run everything as MI instead. |
|
Back to top |
|
 |
exerk |
Posted: Fri Sep 28, 2012 1:51 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
jfecq wrote: |
Local queue at receiving queue manager to persistent. |
This will have no effect on messages received. If a non-persistent message is sent to that queue, that message will remain non-persistent.
jfecq wrote: |
I will run everything as MI. |
A much more sensible approach. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
jfecq |
Posted: Thu Oct 04, 2012 7:52 pm Post subject: |
|
|
Apprentice
Joined: 24 Sep 2012 Posts: 36
|
exerk wrote: |
jfecq wrote: |
Local queue at receiving queue manager to persistent. |
This will have no effect on messages received. If a non-persistent message is sent to that queue, that message will remain non-persistent.
jfecq wrote: |
I will run everything as MI. |
A much more sensible approach. |
I have changed to MI queue manager.
2 VMs for the MI queue manager (X, Y). I set the queue to be persistent.
1 more VM for another MQ (Z). Z has a remote definition to a local queue in the MI queue manager.
x(1414),Y(1414)
I have also set it to persistent but I am not sure if there is any effect.
I then power down Y. X will take some time before switching over. I verified via dspmq -x that X has switched over.
During this switch over period, any messages put via Explorer to the remote queue, SOMETIMES will end up in DLQ of Z, whereas SOMETIMES they are in the transmission queue.
May I know what is actually happening here, and how to prevent the messages from going to DLQ rather than the transmission queue? |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Oct 04, 2012 9:24 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
jfecq wrote: |
May I know what is actually happening here, and how to prevent the messages from going to DLQ rather than the transmission queue? |
Which DLQ? The DLQ at the receiver end of the channel - the channel getting messages from the transmission queue?
When a message is sent to a dead-letter-queue, the MCA creates a dead-letter-header (DLH), and puts it in the DLQ along with the original MQMD and your application data.
Examine the dead-letter-header for the ReasonCode, which will tell you why the message ended up in the DLQ.
Use amqsbcg to print the complete DLH. Post the results here. _________________ 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 |
|
 |
jfecq |
Posted: Thu Oct 04, 2012 10:34 pm Post subject: |
|
|
Apprentice
Joined: 24 Sep 2012 Posts: 36
|
bruce2359 wrote: |
jfecq wrote: |
May I know what is actually happening here, and how to prevent the messages from going to DLQ rather than the transmission queue?
Which DLQ? The DLQ at the receiver end of the channel - the channel getting messages from the transmission queue? |
When a message is sent to a dead-letter-queue, the MCA creates a dead-letter-header (DLH), and puts it in the DLQ along with the original MQMD and your application data.
Examine the dead-letter-header for the ReasonCode, which will tell you why the message ended up in the DLQ.
Use amqsbcg to print the complete DLH. Post the results here. |
The DLQ of Z. The sending end of the channel. I can't really replicate everytime. Managed to get a message though.
Code: |
AMQSBCG0 - starts here
**********************
MQOPEN - 'DLQ'
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 437
Format : 'MQDEAD '
Priority : 0 Persistence : 1
MsgId : X'414D51206D71716D677220202020202038C66E5020028102'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'mqqmgr '
** Identity Context
UserIdentifier : 'mquser '
AccountingToken :
X'1601051500000027488490BDC8A78788F5A0E2E803000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '11'
PutApplName : 're MQ\java\jre\bin\javaw.exe'
PutDate : '20121005' PutTime : '13541153'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 174 bytes
00000000: 444C 4820 0100 0000 0F01 0000 2020 2020 'DLH ........ '
00000010: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000040: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 2020 2020 2202 0000 ' "...'
00000070: B804 0000 4D51 5354 5220 2020 0B00 0000 '....MQSTR ....'
00000080: 6562 5370 6865 7265 204D 515C 6269 6E5C 'ebSphere MQ\bin\'
00000090: 7275 6E6D 7163 686C 2E65 7865 3230 3132 'runmqchl.exe2012'
000000A0: 3130 3035 3133 3536 3130 3836 3939 '10051356108699 '
No more messages
MQCLOSE
MQDISC |
|
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Oct 05, 2012 5:38 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
What errors did you find in the AMQERR01.LOG file around the time you ran this test - on the sending qmgr? _________________ 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 |
|
 |
jfecq |
Posted: Sun Oct 07, 2012 5:49 pm Post subject: |
|
|
Apprentice
Joined: 24 Sep 2012 Posts: 36
|
Didnt seems anything unusual in the amqerr01.log. But if I didnt mistaken, this time the messages are in the transmission queue initially, but went into the DQL.
Code: |
MQGET of message number 10
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 437
Format : 'MQDEAD '
Priority : 0 Persistence : 1
MsgId : X'414D51206D71716D677220202020202038C66E50203CA106'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'mqqmgr '
** Identity Context
UserIdentifier : 'mquser '
AccountingToken :
X'1601051500000027488490BDC8A78788F5A0E2E803000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '11'
PutApplName : 're MQ\java\jre\bin\javaw.exe'
PutDate : '20121008' PutTime : '01391663'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 174 bytes
00000000: 444C 4820 0100 0000 0F01 0000 2020 2020 'DLH ........ '
00000010: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000040: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 2020 2020 2202 0000 ' "...'
00000070: B804 0000 4D51 5354 5220 2020 0B00 0000 '....MQSTR ....'
00000080: 6562 5370 6865 7265 204D 515C 6269 6E5C 'ebSphere MQ\bin\'
00000090: 7275 6E6D 7163 686C 2E65 7865 3230 3132 'runmqchl.exe2012'
000000A0: 3130 3038 3031 3339 3536 3138 6464 '100801395618dd ' |
Code: |
----- amqccita.c : 3473 -------------------------------------------------------
10/8/2012 09:38:34 - Process(5468.1) User(mquser) Program(runmqchl.exe)
Host(WMQ01)
AMQ9202: Remote host 'fteagent (192.168.1.145) (1514)' not available, retry
later.
EXPLANATION:
The attempt to allocate a conversation using TCP/IP to host 'fteagent
(192.168.1.145) (1514)' was not successful. However the error may be a
transitory one and it may be possible to successfully allocate a TCP/IP
conversation later.
ACTION:
Try the connection again later. If the failure persists, record the error
values and contact your systems administrator. The return code from TCP/IP is
10060 (X'274C'). The reason for the failure may be that this host cannot reach
the destination host. It may also be possible that the listening program at
host 'fteagent (192.168.1.145) (1514)' was not running. If this is the case,
perform the relevant operations to start the TCP/IP listening program, and try
again.
----- amqccita.c : 1290 ------------------------------------------------------- |
|
|
Back to top |
|
 |
|