| Author |
Message
|
| kiran areti |
 Posted: Tue Jun 17, 2014 10:13 pm Post subject: Heartbeat acknowledgement |
 |
|
Newbie
Joined: 17 Jun 2014
Posts: 4
|
| how can i identify a Heartbeat acknowledgement received at sender side queue manager in mq? |
|
| Back to top |
|
 |
| AkankshA |
| Posted: Tue Jun 17, 2014 11:16 pm Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
Why would you want to catch that ?
Any specific error you are facing ? |
|
| Back to top |
|
|
| kiran areti |
| Posted: Wed Jun 18, 2014 12:27 am Post subject: |
|
|
Newbie
Joined: 17 Jun 2014
Posts: 4
|
| I want to know the status of the receiver channel at remote queue manager by heartbeat acknowledgement. This is the reason why i want to identify heartbeat acknowledgement. |
|
| Back to top |
|
|
| MQsysprog |
| Posted: Wed Jun 18, 2014 12:39 am Post subject: |
|
|
Centurion
Joined: 24 Feb 2014
Posts: 116
|
| You could use the functions of confirm of arrival ,or confirm of delivery ,at the message level . |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Jun 18, 2014 4:41 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| kiran areti wrote: |
| I want to know the status of the receiver channel at remote queue manager by heartbeat acknowledgement... |
Hmmm, well if you set your channel stanzas correctly, the sender channel will give you a good indication.
Try
| Code: |
CHANNELS:
AdoptNewMCA=ALL
AdoptNewMCACheck=ALL
MaxChannels=1000
MaxActiveChannels=1000
TCP:
KeepAlive=Yes
|
Adjust your max channels to what you want. Do this on both Qmgrs. Changes to stanzas take affect at the next Qmgr start.
What problem are you experiencing?
What version of MQ and OS on both sides? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 18, 2014 5:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQsysprog wrote: |
| You could use the functions of confirm of arrival ,or confirm of delivery ,at the message level . |
Yeesh - that gets sticky quickly. If the confirmation message doesn't arrive, does that mean the unreliable channel didn't deliver the original message yet, or hasn't delivered the confirmation message yet? When do you send a second original? What happens if the confirmation of the first arrives after you've resent the original?
...etc, etc, etc....
And if the response is "I just want to know it was delivered, I don't plan on resending the original" then why not set the message persistence and rely on the very expensive IBM software you've paid for to do what you bought it to do?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 18, 2014 5:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kiran areti wrote: |
| I want to know the status of the receiver channel at remote queue manager by heartbeat acknowledgement. |
Why? What value does this information have for you? What action will you take in response to (for example) discovering that the receiver MCA is down and how will this differ from the automatic action of the sender MCA in response to this information?
It's still not clear what you're trying to achieve here.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 18, 2014 5:48 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I suspect that you want to know if the channel is really in RUNNING state or not before you/your application attempts to send another message. Is this the case? This subject has been discussed here many, many times.
RUNNING state means that either the channel is currently transmitting a message batch; OR that it believes that it will be able to do so the next time it tries.
It is possible that the channel could fail a few nanoseconds after a successful heartbeat was sent (acknowledged). If the next try fails, channel software will retry from time to time according to your retry-count and retry-interval setting values.
As your were asked in a prior post, what is issue you face?
_________________
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.
Last edited by bruce2359 on Wed Jun 18, 2014 5:53 am; edited 1 time in total |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Jun 18, 2014 5:51 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
It is rarely a good idea for the application itself to try and work out the health of the system. Life gets very complicated very quickly. Far better to leave the system health to the operators and their monitoring tools.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| MQsysprog |
| Posted: Wed Jun 18, 2014 8:43 pm Post subject: |
|
|
Centurion
Joined: 24 Feb 2014
Posts: 116
|
I like the concepts we gave to this thread ,to summarize a good discussion is our harvest here .
I saw several cases of applications trying to monitor their state by itself ,and i agree with Paul ,this action breaks in some way an indetermination principle ,meaning that the monitoring gives some perturbations to the application itself .
The request reply model ,is similar to the old conversional model used at the old age of bsc lines ...
But MQ is designed with this feature ,so trying to use it may be better than nothing .
One possible alternative is an heartbeat message with timeout ,for example one every five normal payload messages to have a sampling of the connection state .
Ciao
Emanuele |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 18, 2014 9:16 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| MQsysprog wrote: |
| But MQ is designed with this feature ,so trying to use it may be better than nothing . |
What feature?
| MQsysprog wrote: |
| One possible alternative is an heartbeat message with timeout ,for example one every five normal payload messages to have a sampling of the connection state . |
For what purpose? Why does your application need to know channel state?
_________________
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 |
|
|
| Vitor |
| Posted: Thu Jun 19, 2014 5:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQsysprog wrote: |
| But MQ is designed with this feature ,so trying to use it may be better than nothing . |
No. It's designed with this feature so that the MCAs can work as designed. It's not intended for use by applications, and WMQ itself is designed on the predicate that the applications can be assured (note the IBM term) messages will be delivered without getting involved in the transport layer.
Consider this: before you post a letter, do you check with the postal service that whoever usually collects the mail turned up for work? That the van that transports the mail is servicable? That whoever sorts and delivers the mail isn't on vacation? Or do you just post the letter confident it will turn up?
| MQsysprog wrote: |
| One possible alternative is an heartbeat message with timeout ,for example one every five normal payload messages to have a sampling of the connection state . |
So answer me this - using the method you outline above your application determines that there's a connection problem (and I don't see from what you've outlined how it could detect more than that basic fact). What does your application do with that information? Does it stop transmitting? Shut down? How does it detect when the problem is resolved and can restart? How is that better than what the WMQ software provides?
I don't see the point you're making. Which is not to say you don't have a point.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 19, 2014 7:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| kiran areti wrote: |
| I want to know the status of the receiver channel at remote queue manager by heartbeat acknowledgement. This is the reason why i want to identify heartbeat acknowledgement. |
Most likely, if the sender channel is in RUNNING state, the receiver channel will also be in RUNNING state. If the network fails (someone cuts the cat5 cable, for example), the sender channel will discover this failure with the next attempt to send a batch of messages or at the next heartbeat attempt.
Back to the question you've been asked a few times here: for what purpose do you (or your application) need to know the state of the channel? Are you writing a monitoring application?
Is your intent is to delay producing messages until the channel comes back to life? If so, how long will you wait until you next test for RUNNING state? How often (in milliseconds or seconds) do you intend to wait? What if the channel comes back to life before your application wait expires? Or do you intend to continuously inquire on channel status?
_________________
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 |
|
|
|
|
