| Author |
Message
|
| Michael Dag |
 Posted: Tue Nov 06, 2007 10:53 pm Post subject: |
 |
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| bruce2359 wrote: |
MQ does NOT lose messages.
MQ does NOT lose messages.
MQ does NOT lose messages.
Repeat as necessary. |
If you have seen Harry Potter and the Order of the Phoenix...
take out your feather and start writing 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
 |
| JYama |
| Posted: Tue Nov 06, 2007 11:23 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
| JYama wrote: |
What I can't understand is that it seemed MQ cluster was keeping routing incoming msgs to the route to QMgr2 which should not be chosen as a valid route because the node (containing QMgr2) was not available.  |
Now get back to basics.
1. Can clussdr channels be alive when the target listener is not working?
(I think NO. In my case, the node was down by 'halt -q' so MQ listener was not available.)
2. How can clussdr channels recognize a network error and become 'RETRYING'?
(I think there're various cases such as the first msg exchange between the QMgrs, HBINT expiration, and etc.)
One interesting thing in my case is that the status in 'RUNNING' didn't change even the first msg had been exchanged unsuccessfully. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 07, 2007 1:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Getting back to basics:
1) MQ does not lose persistent messages, even in clusters. It may put them someplace you don't expect, but it won't lose them.
2) If it does, and you can do so repeatably, you should raise a PMR.
3) If you need detailed information on how the MCAs detect and respond to problem issues, then IBM is the only definative source of such information.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ChrisW |
| Posted: Wed Nov 07, 2007 5:53 am Post subject: |
|
|
Voyager
Joined: 20 May 2001
Posts: 78
Location: UK
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 07, 2007 7:41 am Post subject: |
|
|
Guest
|
| Quote: |
| I believe this non-per msg would be lost even if NPMSPEED=NORMAL. |
Yes, a non-persistent message will not survive a qmgr restart. So, if a non-persistent message arrives on a queue, and you restart the qmgr, the message will be purged. This is working as designed. And this is why non-persistent messages are not suitable for many business applications. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Nov 07, 2007 7:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
All non-persistent messages on queues that have NPMCLASS(HIGH) will be retained during qmgr restart, if at all possible.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 07, 2007 9:19 am Post subject: |
|
|
Guest
|
| Quote: |
| All non-persistent messages on queues that have NPMCLASS(HIGH) will be retained during qmgr restart, if at all possible. |
And, by 'if at all possible' Jeff means that the qmgr shuts down normally. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 07, 2007 11:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
holy moly this thread is something else.
When dealing with "lost" messages check all these things first. If you are certain that none apply and you still cant find the message, you have a legitimate problem.
See this post for a list of reasons why you thing MQ lost your message but it really didn't:
http://www.mqseries.net/phpBB2/viewtopic.php?p=197055#197055
It was my understanding that none of these things applied for JYama, so he really has missing messages. Also, he has the issue of the channel taking forever to go into retrying.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 07, 2007 11:38 am Post subject: |
|
|
Guest
|
| Quote: |
| When dealing with "lost" messages ... |
This really means 'when dealing with apparently or reportedly lost messages...' because MQ doesn't lose messages.
This is the base line from which we do our analysis. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 07, 2007 11:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I guess that boils down to what lost means. I'm not lost, I'm just temporarily geographicaly disabled! My car keys wern't lost this morning, I just didn't know where to look for them. That MQ message is not lost, you just don't know where to look for it! Or one dosn't understand that by design the scenario caused that message to be destroyed.
In this conext I suppose there is no such thing as a lost message.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 07, 2007 12:05 pm Post subject: |
|
|
Guest
|
If MQ managed your car keys (and they are persistent), then they'd either be in the destination queue; or in a transmission queue; or dead-letter queue.
Otherwise, there were no car keys. |
|
| Back to top |
|
|
| JYama |
| Posted: Wed Nov 07, 2007 5:31 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
Thank so much for your help, all. I really really appreciate that.
After my careful consideration based on our discussion, I've reached to one question.
What happens if there are multiple messages routed and comming into a clussdr channel in INDOUT status? 
Does anybody know that?
Regards, |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 07, 2007 5:43 pm Post subject: |
|
|
Guest
|
channel in INDOUBT status
A quick check of the MQ Intercommunications manual will tell you that INDOUBT means that the channel is not running - no messages flowing; and more importantly that the MCAs at either end cannot agree on message sequence wrap (the number of messages sent/received.
You really need to read the Intercom manual to fully understand when and how messages flow across a channel, and how to resolve channel problems. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 07, 2007 5:52 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If the channel is In Doubt and NEW messages arrive the cluster will just send them down another channel, unless the only possible destination for the messages is the QM whose channel is in doubt, in which case they will sit in the S.C.T.Q. until the channel is problem resolved.
If you got a channel in doubt, that means there are one or more messages stuck inside the channel. You can either back them out, in which case they will be eligible to be sent by the cluster someewhere else, assuming they can go to another QM, or you can commit them in which case you are telling the channel you know the other side got them and the sending side of the channel can stop worrying about them.
Make the wrong choice in commit versus backout and you can either lose messages (there's another one for the list!) or duplicate messages. Read the fine manuals on this subject before you start manually resolving channels.
| Quote: |
This command is used when the other end of a link fails during the confirmation period, and for some reason it is not possible to reestablish the connection.
In this situation the sending end remains in doubt, as to whether or not the messages were received. Any outstanding units of work need to be resolved by being backed out or committed.
Care must be exercised in the use of this command. If the resolution specified is not the same as the resolution at the receiving end, messages can be lost or duplicated. |
It may not be possible to resolve the CLUSSNDR you need to:
| Quote: |
| Where there is both a locally defined channel and an auto-defined cluster-sender channel of the same name, the command applies to the locally defined channel. If there is no locally defined channel but more than one auto-defined cluster-sender channel, the command applies to the channel that was last added to the local queue manager’s repository. |
There is a very small window where a channel can go in doubt. Using Batch Heartbeats the chances go down even more. But an In Doubt channel can definitly explain your lost, I mean, your misplaced messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JYama |
| Posted: Wed Nov 07, 2007 10:08 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
Excellent summary!
Since I don't know how my MQ server node got down when I entered 'halt -q' , NP-msg delivery depends on it, there's also a delicate timing of NP-msg delivery between the QMgr and the msg consumer, I've concluded my case. 
| Quote: |
The message was NP and sitting on a q which is set to NPMCLASS(NORMAL) and the QM restarts
|
Although now there's no way to confirm what exactly happend in the node during my test (because the node got shutdown and there's no record in various logs), this is the only scenario which explains my case.
Many thanks to great participants and I'm deeply grateful for your expertise!
Great members!  |
|
| Back to top |
|
|
|
|
