| Author |
Message
|
| Kristoffer |
 Posted: Tue Nov 28, 2006 1:27 am Post subject: Messages seems to dissappear in transit between QMs |
 |
|
Novice
Joined: 21 Nov 2006
Posts: 15
Location: Sweden
|
I have encountered a problem where messages seems to dissappear even though everything in the setup is ok as far as I can see.
An application (WBIMB 5.2) puts a message to a remote queue definition set up on QM1. The remote queue definition points to a local queue on QM3 and XMITQ is set to QM2 where the channels and transmission queues for QM3 is located.
On QM2 the sender channel and transmission queues are setup with default values and works fine most of the time. It's important to point out that the network link between QM2 and QM3 is slow and a bit error prone.
Most of the time everything works fine, messages goes all the way through. Sometimes, however, we're notified that messages are missing on the destination queue. In these situations the sender channel (QM2/QM3) is usually in an inactive state, but the missing messages does not show up on the transmission queue. When we try to start the channel from inactive state we get an error message and have to change it to a stopped status before starting it, putting it in a Running state. We've never "lost" messages when the channel is in a running state before sending them.
Our suspicions points in the direction that the bad network link causes the channel to fail to inactive state, but this shouldn't cause the messages to vanish into thin air since they are persistent all the way.
Any clues? Should I change any parameters on the channel?
When I encounter this problem again I'll record the error code I receive then trying to start the channel from Inactive state. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Nov 28, 2006 1:38 am Post subject: Re: Messages seems to dissappear in transit between QMs |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Kristoffer wrote: |
Any clues? Should I change any parameters on the channel?
When I encounter this problem again I'll record the error code I receive then trying to start the channel from Inactive state. |
You should look at the logs on both ends to see if the channels are having problems.
You might also want to look into using a RESOLVE CHANNEL command to backout messages rather than a stop/start. One possible scenario is that the channel has experienced the bad network connection you mention, and the "missing" message are in fact in an in-doubt state. When you bounce the channel, the status is reset and these messages are lost.
Errors and log entries will prove or disprove this theory. As will DISPLAY CHSTATUS on the inactive channel.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tleichen |
| Posted: Tue Nov 28, 2006 6:48 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
Not to state the obvious, but have you checked the DLQ? 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| Kristoffer |
| Posted: Wed Nov 29, 2006 12:14 am Post subject: |
|
|
Novice
Joined: 21 Nov 2006
Posts: 15
Location: Sweden
|
| tleichen wrote: |
| Not to state the obvious, but have you checked the DLQ? |
Yes, I have, and there's nothing there on any of the QMs involved. Right now I'm waiting for the problem to occur again so I can try out Vitors tip.
I might also add this information: When starting the sdr channel from stopped state it takes about 5-10 seconds before it's up and running. Can it be some kind of timeout that prevents the channel from going from Inactive -> Running when messages arrive?
Also, log files have been very helpful this far.  |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 29, 2006 12:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Kristoffer wrote: |
I might also add this information: When starting the sdr channel from stopped state it takes about 5-10 seconds before it's up and running. Can it be some kind of timeout that prevents the channel from going from Inactive -> Running when messages arrive?
|
It sounds like the 2 MCAs are trying to resyncronise by reset, which implies that they're chewing on your messages. Especially if there's nothing significant in the logs because they're functioning as designed.
I become more confident a RESOLVE will help. On the understanding I've been wrong before of course.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Nov 29, 2006 3:21 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
RESOLVE is definitely the wrong action to take. The channels will synchronise automatically, and do not need to be told what to do.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 29, 2006 3:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Nigelg wrote: |
| RESOLVE is definitely the wrong action to take. The channels will synchronise automatically, and do not need to be told what to do. |
Even if the channel status is in-doubt?
Under what circumstances would the RESOLVE command be used then?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 29, 2006 3:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Nigelg wrote: |
| RESOLVE is definitely the wrong action to take. The channels will synchronise automatically, and do not need to be told what to do. |
And, to return to the topic, if the channels are correctly resyncronising where are these persistent messages going? If not delivered, I'd have at least expected them to end up on one or other of the DLQ.
Kristoffer - can you confirm (for the paranoid amongst us like me) that you have a DLQ on both of the queue managers involved?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Nov 29, 2006 3:47 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Vitor wrote: |
| Nigelg wrote: |
| RESOLVE is definitely the wrong action to take. The channels will synchronise automatically, and do not need to be told what to do. |
And, to return to the topic, if the channels are correctly resyncronising where are these persistent messages going? If not delivered, I'd have at least expected them to end up on one or other of the DLQ.
|
unless there is a default xmitq defined somewhere... 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 29, 2006 3:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MichaelDag wrote: |
| unless there is a default xmitq defined somewhere... |
Kristoffer ..... ?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Nov 29, 2006 4:53 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
Under what circumstances would the RESOLVE command be used then?
|
1. When the channel is in-doubt
AND
2. When you know that the msgs are never going to be delivered to the original destination, i.e. the qmgr/machine does not exist any more, and so can not reply to any resync request.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Nov 29, 2006 4:56 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A default XMITQ wouldn't intermittently cause message failure. Unless the application intermittently failed to specify the right destination.
Kristoffer - what is the error message that occurs when you try to start the channel from inactivity?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 29, 2006 4:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Nigelg wrote: |
| Quote: |
Under what circumstances would the RESOLVE command be used then?
|
1. When the channel is in-doubt
AND
2. When you know that the msgs are never going to be delivered to the original destination, i.e. the qmgr/machine does not exist any more, and so can not reply to any resync request. |
Number 1 is exactly the scenario I described as possible. I even referred to the in-doubt status & how to check for it before using the command.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Nov 29, 2006 6:04 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Vitor wrote: |
| Nigelg wrote: |
| Quote: |
Under what circumstances would the RESOLVE command be used then?
|
1. When the channel is in-doubt
AND
2. When you know that the msgs are never going to be delivered to the original destination, i.e. the qmgr/machine does not exist any more, and so can not reply to any resync request. |
Number 1 is exactly the scenario I described as possible. I even referred to the in-doubt status & how to check for it before using the command. |
Yes....but Nigel is saying both conditions should be meet before the resolve is used...thats what the and means  |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 29, 2006 6:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Never afraid to bow to someone with greater knowledge (and apparently better language skills  )!
We await the reoccurance of the original problem, and more diagnostics then. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
