| Author |
Message
|
| Vitor |
 Posted: Wed Nov 29, 2006 7:01 am Post subject: RESOLVE CHANNEL |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Under what circumstances have people seen a channel with in-doubt status? Has anyone ever used RESOLVE CHANNEL, when, why and what happened?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Wed Nov 29, 2006 7:26 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
A non-transient indoubt status is easy to achieve.
It happens when the network connection has gone down after the sender channel has sent the last msg in a batch, and before the receiver channel has sent the confirm reply back.
Of course, every channel is indoubt for a short time after each batch, until the confirm reply is received, but usually this lasts only a few milliseconds at most.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 29, 2006 7:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Would you agree that such a status should be resolved automatically when the network connection is restored?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dgolding |
| Posted: Wed Nov 29, 2006 7:53 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
The only time I've seen a channel in-doubt was when there was crash of the queue manager on the receiving side (NOT a system or network problem, the qmgr itself died).
I've definitely seen it on a receiving Unisys mainframe when the qmgr crashed there at least twice. I've got a feeling we got it with a receiving DEC VMS qmgr but couldn't swear to it.
HTH |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Nov 29, 2006 8:33 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| Would you agree that such a status should be resolved automatically when the network connection is restored? |
Yes, when the channel restarts.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Nov 29, 2006 8:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Originally I posted this in the other thread, so I've deleted it and moved it here...apologies.
| jefflowrey wrote: |
In general, I think this doesn't help with Kristoffer's problem.
In specific, I've never needed to issue a RESOLVE CHANNEL. |
Unfortunately I have...due to a firewall/routing problem where there was enough connectivity for a SDR/RCVR to run, but not enough for the commit response to be received. The CURLUWID and LSTLUWID mismatched and BACKOUT RESOLVE was the only option.
Problem was due to VCS-controlled queue manager fail-over to second node and rules not being in place for the fail-over node; nice little 'gotcha'.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Nov 29, 2006 8:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
So under what circumstances would you need to use a RESOLVE CHANNEL with COMMIT? If the channel is in doubt because the target queue manager has gone the way of all flesh, you'd use BACKOUT to retrieve the messages and pass them to their intended (new) destination?
Or am I being thicker than a whale sandwich here?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Nov 29, 2006 8:54 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
So under what circumstances would you need to use a RESOLVE CHANNEL with COMMIT? If the channel is in doubt because the target queue manager has gone the way of all flesh, you'd use BACKOUT to retrieve the messages and pass them to their intended (new) destination?
Or am I being thicker than a whale sandwich here? |
Presumably if the SDR/RCVR LUWID's were identical but the SDR qmgr has not received, or is unsure it's received the commit...I'm assuming a communication problem here rather than the RCVR end going belly up.
Would you chance it though?
_________________
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 |
|
|
| bruce2359 |
| Posted: Wed Nov 29, 2006 11:48 am Post subject: |
|
|
Guest
|
Read the Problem Determination chapter in the Intercommunications manual. It discusses RESOLVE issues.
Messages are sent/received in units of work. If either end detects that the logical unit of work id and/or sequence number don't match, the channel is IN-DOUBT.
RESOLVE COMMIT commits the messages out of the xmit queue and commits them into the destination queue(s). RESOLVE BACKOUT backs out messages from destination queue(s) and back into the xmit queue. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Nov 30, 2006 1:52 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
If either end detects that the logical unit of work id and/or sequence number don't match, the channel is IN-DOUBT.
|
No. See my post above for when a channel goes indoubt.
The situation described by bruce would cause the channel to fail to go to RETRYING status with a sequence number msg written to the error logs.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Mon Dec 04, 2006 12:34 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
In MQ 5.0, I have seen many INDOUBT channel status messages. I have used RESOLVE many times to get a channel running. Not so much in 5.1, and very seldom in 5.2/3.
Here is my understanding of the difference between a simple channel sequence number error and an in-doubt status. I hope that the grandmasters will be kind if I use any terminology incorrectly as I state this concept.
A sender goes into retry when it has not gotten an ack back from the receiver. That does not mean that the receiver didn't get the message, just that the ack didn't get back to the sender. Usually, I think, this is caused by an interruption in the sender's communication with the receiver. By sending a RESET, the sender is asking "did you get it? oh, you did? let's sync our sequence numbers and move on".
If you watch closely, you will see (as someone else mentioned) that a running channel goes into INDOUBT as it waits for the ack back from the receiver. It is so fast that you can only ever see it on really busy channels.
If that running in-doubt channel never gets the ack back, the sender goes to RETRYING and INDOUBT=YES. A sender will never send its next message until it is sure that the current one is received.
So, at this point with your RETRYING channel, you first try a RESET. Sometimes that works, if in fact the sender can confirm that the receiver got the message.
If the sender cannot confirm receipt, then RESET will not sync those sequence numbers. The sender channel remains "in-doubt" as to whether the message was ever received on the other side.
At this point, MQ wants you (a human) to make a decision about the message whose receipt is indoubt. Do you want to send it again? Then choose RESOLVE(BACKOUT). But maybe you have checked the application on the receiving end and you know that the data was received and you know you do not want duplicate data to be sent. In that case, you would choose RESOLVE(COMMIT).
All this to support my answer to the question:
| Quote: |
Would you agree that such a status should be resolved automatically when the network connection is restored?
|
My answer is absolutely not. I think this aspect of channel operation is at the heart of "guaranteed one-and-once-only delivery" that is the hallmark of MQSeries.
Now this is mainly a concept I have derived from reading the manuals and then seeing MQ at work. So I guess I am prepared for other opinions!
Shirley |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Dec 05, 2006 12:36 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
SAFraser, you are absolutely 100% wrong. The indoubt status is resolved without any human intervantion when the channel restarts.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Dec 05, 2006 5:55 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
SAFraser wrote: "If that running in-doubt channel never gets the ack back, the sender goes to RETRYING and INDOUBT=YES. A sender will never send its next message until it is sure that the current one is received."
In the case I mentioned the channel never went into retry, it showed a continuous running status.
I'll restate: The channel 'handshake' was not a problem, the 'commit' acknowledgement was. I'm not a TCP/IP expert but assume that the session ack packet(s) and message ack packet(s) are different and that a firewall may filter the message ack packet(s) if not set up correctly. We have another test in the pipeline soon so I will be able to expand on this in a later post.
_________________
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 |
|
|
| kevinf2349 |
| Posted: Tue Dec 05, 2006 5:58 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| exerk wrote: |
In the case I mentioned the channel never went into retry, it showed a continuous running status.
I'll restate: The channel 'handshake' was not a problem, the 'commit' acknowledgement was. I'm not a TCP/IP expert but assume that the session ack packet(s) and message ack packet(s) are different and that a firewall may filter the message ack packet(s) if not set up correctly. We have another test in the pipeline soon so I will be able to expand on this in a later post. |
but we aren't talking about your case here, we are talking about using RESOLVE in general aren't we?  |
|
| Back to top |
|
|
| SAFraser |
| Posted: Tue Dec 05, 2006 8:42 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
NigelG,
As I mentioned, I cannot remember seeing this much (if ever) in v5.3. But I can assure you that I have had to manually resolve many a channel (between Windows & Tandem) when running older versions of MQ. So the in-doubt status was not automatically resolved.
Then when, in your scenario, would you ever need the RESOLVE function?
exerk,
If you have a running channel that is continuously indoubt, that may be because it is very busy. INDOUBT on a running channel is not bad, it is just informative. If there are no messages flowing and it is INDOUBT, that's another matter. Perhaps you can tell us more about your situation.
Shirley |
|
| Back to top |
|
|
|
|
