ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » remote queue switchover loses messages

Post new topic  Reply to topic
 remote queue switchover loses messages « View previous topic :: View next topic » 
Author Message
jfecq
PostPosted: Thu Sep 27, 2012 11:00 pm    Post subject: remote queue switchover loses messages Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Fri Sep 28, 2012 12:10 am    Post subject: Reply with quote

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
View user's profile Send private message
jfecq
PostPosted: Fri Sep 28, 2012 1:33 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Fri Sep 28, 2012 1:42 am    Post subject: Reply with quote

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
View user's profile Send private message
jfecq
PostPosted: Fri Sep 28, 2012 1:49 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Fri Sep 28, 2012 1:51 am    Post subject: Reply with quote

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
View user's profile Send private message
jfecq
PostPosted: Thu Oct 04, 2012 7:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Thu Oct 04, 2012 9:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
jfecq
PostPosted: Thu Oct 04, 2012 10:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Fri Oct 05, 2012 5:38 am    Post subject: Reply with quote

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
View user's profile Send private message
jfecq
PostPosted: Sun Oct 07, 2012 5:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » remote queue switchover loses messages
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.