| Author |
Message
|
| wangr |
 Posted: Mon Dec 16, 2013 7:01 pm Post subject: reset the channel or resolve the channel |
 |
|
Newbie
Joined: 19 Jun 2013
Posts: 5
|
our mq server has just been patched, and queue managers are restart and running.
the issues is the channel communication error occurs between the patched QM and its partner QM (the channel pair is sender and receiver). Now the sender channel state is "retrying" and the error logs shows there is a dismatch of sequence number between sender and receiver...
My question for this case is:
1. Can the sender channel be considered as an in doubt channel? (its status shown in the mq exploer is "retrying"
2. What we did is: stop the sender channel, reset its seq number to 1, and then start it (during this period there are some pending messages on the transmission queue). Now the channel is up and running, messages are sent to the receiver side and at last transmission Q is empty. so far so good...
The problem is MQ application users complains that they seem lost some messages. We checked in our MQ side that there is no pending messages in both transmission queue and dead letter queue. So is that possible that MQ lost the messages during the transmission process due to the reset channel? and in the future for similar case, should we try to resolve the channel (either commit or backout depends on the batch ID)? Here I'm not sure if the channel should in doubt channel.
In general, when can we safely reset channel and when must we resolve the channel?
3. being an MQ admin, how can we prove that our mq system sends all the messages correctly? Is that possible to prove that?
Thanks. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Dec 16, 2013 9:42 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
From your own research here or on google, what is the purpose of the RESET script command? What is the purpose of the RESOLVE command?
From your own research, what does channel INDOUBT signify?
_________________
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 |
|
|
| smdavies99 |
| Posted: Tue Dec 17, 2013 2:32 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
There is one tip you can use to stop anything like this from happening in the future.
That is to STOP to stop all applications and then let all outgoing messages be processed prior to shutting down the queue manager.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Dec 17, 2013 5:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
There is no need for you to be in doubt on whether your channel is in doubt. There is a channel status attribute that tells you Yes/No on its in doubt status. Its normal for a sending channel to be very, very briefly in doubt after every batch of messages it sends, and this in doubt situation is resolved automatically in milliseconds. Sometimes things go wrong, your channel is left stuck in an in doubt condition and the MQ error logs will tell you as much. Review this:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.con.doc/q015690_.htm
You should not automatically reset sequence numbers. If you could do it automatically with no risk, then I'm sure IBM would have just coded MQ to do it for you. Typically the most common reason you are out of sequence is:
1.Someone incorrectly reset the sequence number on the receiving side
2.Someone redefined the receiving channel and let the new channel default to 1 for sequence number
3.You are in some home grown fail over scenario where the original receiving QM is gone and you are now attempting to connect to another QM with the same channel name
4.Something went wrong.
MQ uses sequence numbers to keep track of messages.
You paid a lot of money for MQ to keep track of messages.
Don't blindly reset sequence numbers until you know why they are out of sync.
And don't resolve in doubt channels with out the proper diagnosis! A sure way to have a 50/50 chance of either duplicating messages or destroying them.
If I had to pick one doc that can help an MQ Admin's pager stay dormant, this is it:
http://www-01.ibm.com/support/docview.wss?uid=swg24006699
smdavies99, I'll respectfully disagree with you. I don't think that is needed to prevent sequence number issues - MQ channels are designed to handle unexpected and abrupt disruptions with their partner channel. Sequence number problems are rarely if ever caused because a sending or receiving QM shut down while channels were processing messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Dec 17, 2013 6:07 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| PeterPotkay wrote: |
smdavies99, I'll respectfully disagree with you. I don't think that is needed to prevent sequence number issues - MQ channels are designed to handle unexpected and abrupt disruptions with their partner channel. Sequence number problems are rarely if ever caused because a sending or receiving QM shut down while channels were processing messages. |
I proposed that way simple because when doing a planned shutdown for maintenance like this I like to make sure evething is disconnected from the QMGR and it is 'quiet'. Then when stopping the qmgr you have a relatively clean (i.e. no messages in transit) situation. Then you can bring the QMGR up after the upgrade and check things out before gradually letting the various apps loose again. Perhaps I am far too cautious but that is just me I suppose. I guess that goes back to the days of doing RSX-11M Sysgens and hoping, fingers crossed that the system would boot again. I love clean builds and really hate messy systems.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 17, 2013 6:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A normal qmgr shutdown allows the channels to quiesce (when the in-flight batch of messages completes). There is no need to stop channels prior to qmgr shutdown.
For those who are curious or too young, RSX-11 is/was a family of real-time operating systems mainly for PDP-11 computers created by Digital Equipment Corporation (DEC), common in the late 1970s and early 1980s. RSX-11D first appeared on the PDP-11/40 in 1972.
Try not to base your present-day decisions and behaviors on 40+ year old technology.
_________________
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 |
|
|
| smdavies99 |
| Posted: Tue Dec 17, 2013 8:25 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| bruce2359 wrote: |
Try not to base your present-day decisions and behaviors on 40+ year old technology. |
Maybe not but I have learned over the years to be very careful when doing any upgrades and to make sure that I have a way out in case things go wrong.
Better to be safe and sure. This reference says it all really
http://answers.yahoo.com/question/index?qid=20110904034654AAT5seq
PS
I spent 20 happy years working for the CSS group at DEC in Reading. It was for the PDP/RSX system that I wrote a distributed message queuing system in 1981/82. It was embedded deep inside another product.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Tue Dec 17, 2013 2:38 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
| You can reset a channel inside an mqsc session without specifying a new sequence number. I always try this first. If the problem is that the message was received but channel was interrupted before the ack back, the sender and receiver will sort that without human intervention. |
|
| Back to top |
|
|
|
|
