Author |
Message
|
Chandra Mohan |
Posted: Thu Nov 13, 2008 10:27 pm Post subject: Reset MQ Channel |
|
|
 Acolyte
Joined: 26 Jul 2006 Posts: 53
|
Hi Guys,
I have one confusion... if channel come in retrying state because of unexpected no. of message reach to destination. To resolve it we have to reset channel to 1 or expected message #.
My confusion is how reciver end know that this is expected message # i shud get. If he doesn'e then we face problem in communication.
Regards
CM _________________ Chandra Mohan |
|
Back to top |
|
 |
rgprasanna |
Posted: Thu Nov 13, 2008 11:22 pm Post subject: |
|
|
 Voyager
Joined: 02 May 2007 Posts: 91 Location: Chennai - India
|
you can reset the Message sequence no of the channel from 1 to 999 999 999, by default it's 1
when you reset the channel at sender end, it will reset the channel at receiver end also (unlike resetting the channel at receiver end)
hope it answer your question _________________ Prasanna |
|
Back to top |
|
 |
Mr Butcher |
Posted: Thu Nov 13, 2008 11:44 pm Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
you should also investigate why the sequence number differs between sender and receiver, e.g. queuenamager was new created, channel was deleted / defined , ip address was changed or something similiar. for other reasons, the difference in sequence number may be serious. _________________ Regards, Butcher |
|
Back to top |
|
 |
Chandra Mohan |
Posted: Fri Nov 14, 2008 2:42 am Post subject: |
|
|
 Acolyte
Joined: 26 Jul 2006 Posts: 53
|
Guys i understand that what wud be the reason behind the cause. My concern is how reciver end know 4 msg sequence no. is expected.
Regards
CM _________________ Chandra Mohan |
|
Back to top |
|
 |
Chandra Mohan |
Posted: Fri Nov 14, 2008 2:44 am Post subject: |
|
|
 Acolyte
Joined: 26 Jul 2006 Posts: 53
|
rgprasanna wrote: |
you can reset the Message sequence no of the channel from 1 to 999 999 999, by default it's 1
when you reset the channel at sender end, it will reset the channel at receiver end also (unlike resetting the channel at receiver end)
hope it answer your question |
Guys i understand that what wud be the reason behind the cause. My concern is how reciver end know 4 msg sequence no. is expected. If it doesn't get it expected seq # then we face problem in communication.
Regards
CM _________________ Chandra Mohan |
|
Back to top |
|
 |
exerk |
Posted: Fri Nov 14, 2008 4:12 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Chandra Mohan wrote: |
...My concern is how reciver end know 4 msg sequence no. is expected... |
Because the RCVR maintains its own count for that connection, and compares that to the count passed by the SDR. How else would both ends of the channel reconcile the number of messages passed, or to be passed?
From the Intercommunication Manual:
Quote: |
Channel message sequence numbering
The channel uses sequence numbers to assure that messages are delivered, delivered without duplication, and stored in the same order as they were taken from the transmission queue. The sequence number is generated at the sending end of the channel and is incremented by one before being used, which means that the current sequence number is the number of the last message sent. This information can be displayed using DISPLAY CHSTATUS (see WebSphere MQ Script (MQSC) Command Reference ). The sequence number and an identifier called the LUWID are stored in persistent storage for the last message transferred in a batch. These values are used during channel start-up to ensure that both ends of the link agree on which messages have been transferred successfully. |
_________________ 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 |
|
 |
atheek |
Posted: Fri Nov 14, 2008 4:13 am Post subject: |
|
|
 Partisan
Joined: 01 Jun 2006 Posts: 327 Location: Sydney
|
Channel sequence numbers are MQ's way of assuring guaranteed delivery - the sender channel deletes the messages from the xmitq only after it has got the assurance from the receiver channel that it has received those messages. Message sequence numers are used to track this between the channel pairs.
If you get channel sequence error too often it could be a sign that messages are getting lost in the network. |
|
Back to top |
|
 |
Chandra Mohan |
Posted: Fri Nov 14, 2008 7:20 pm Post subject: |
|
|
 Acolyte
Joined: 26 Jul 2006 Posts: 53
|
atheek wrote: |
Channel sequence numbers are MQ's way of assuring guaranteed delivery - the sender channel deletes the messages from the xmitq only after it has got the assurance from the receiver channel that it has received those messages. Message sequence numers are used to track this between the channel pairs.
If you get channel sequence error too often it could be a sign that messages are getting lost in the network. |
Thanks to all of you its really help me to understand this concept.
Atheek can you be more specific on the statement " the sender channel deletes the messages from the xmitq only after it has got the assurance from the receiver channel that it has received those messages." What i understand is its never transfer message it XMITQ send duplicate copy and once it get an acknolwdgment from RCVR end it delete message ? _________________ Chandra Mohan |
|
Back to top |
|
 |
atheek |
Posted: Fri Nov 14, 2008 9:47 pm Post subject: |
|
|
 Partisan
Joined: 01 Jun 2006 Posts: 327 Location: Sydney
|
Yes. What you understood is correct. |
|
Back to top |
|
 |
Chandra Mohan |
Posted: Sat Nov 15, 2008 1:21 am Post subject: |
|
|
 Acolyte
Joined: 26 Jul 2006 Posts: 53
|
atheek wrote: |
Yes. What you understood is correct. |
Could you send tell me the link of docs to support your statment. Because some how its difficult to belive on it as per IBM statement it says:-
- No Redudancy/ duplicate messages.
I understand it sends a copy but i belive if IBM sate as above then they tried their best to refrain from message duplicay condition.
Regadrs
CM _________________ Chandra Mohan |
|
Back to top |
|
 |
atheek |
Posted: Sat Nov 15, 2008 1:38 am Post subject: |
|
|
 Partisan
Joined: 01 Jun 2006 Posts: 327 Location: Sydney
|
The channel transfers messages in a UOW. The sender commits the UOW ( read deleting the messages from the xmitq) only after it receives the positive acknowledgement from the receiver.
This is same as an application receiving a message in a UOW. Even though the message is delivered to the appln, MQ doesn't delete it from the queue until the appln commits the UOW. If the app rollbacks the message is redelivered to the appln. You cant call this as duplicate delivery of the messages
The intercommunication manual explains it all |
|
Back to top |
|
 |
Chandra Mohan |
Posted: Sat Nov 15, 2008 6:49 pm Post subject: |
|
|
 Acolyte
Joined: 26 Jul 2006 Posts: 53
|
atheek wrote: |
The channel transfers messages in a UOW. The sender commits the UOW ( read deleting the messages from the xmitq) only after it receives the positive acknowledgement from the receiver.
This is same as an application receiving a message in a UOW. Even though the message is delivered to the appln, MQ doesn't delete it from the queue until the appln commits the UOW. If the app rollbacks the message is redelivered to the appln. You cant call this as duplicate delivery of the messages
The intercommunication manual explains it all |
PLease tell me UOW refer for ? _________________ Chandra Mohan |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Nov 15, 2008 7:36 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
UOW = Unit of Work = Syncpoint.
In order to ensure that messages are not lost in the transmission process, the Message Channel Agents on both ends of the channel count the number of messages. This count is the SEQWRAP field.
When there is a message in the xmitq, the sending MCA tells the receiving MCA that it is about to send the sequence number of the next message number (SEQWRAP field). The receiving MCA will compare its SEQWRAP message number. If they are equal, the channel will send/receive messages. If the sequence numbers do not match, it means that message (may) have been lost.
The sending MCA MQGETs a message from the xmitq IN_SYNCPOINT, increments the sequence number, and sends the message to the receiving MCA. The receiving MCA MQPUTs each message in the destination queue (or DLQ) IN_SYNCPOINT, and increments the sequence number.
When the receiving end MCA successfully completes MQPUTting the messages (a batch), it sends a confirmation back to the sending MCA to MQCMIT out of the xmitq the messages successfully delivered.
This sequence of events is repeated for each message. _________________ 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 |
|
 |
fjb_saper |
Posted: Sat Nov 15, 2008 8:35 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Bruce,
I'm sure this is just a typo, but it looks to me your hands went away from you and typed SEQWRAP instead of SEQNUM.
For clarification SEQWRAP should be identical at both ends of the channel and determines when SEQNUM can be reused... ex: if seqwrap is set to 99 you'd be using seqnum 0->99 and then wrapping around to seqnum=0 again...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Nov 15, 2008 8:41 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Good eye. See what happens when I multi-task?. Thanks for catching it. Yes, SEQWRAP is the size of the field; SEQNUM is the message count. _________________ 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 |
|
 |
|