ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportHeartbeat acknowledgement

Post new topicReply to topic
Heartbeat acknowledgement View previous topic :: View next topic
Author Message
kiran areti
PostPosted: Tue Jun 17, 2014 10:13 pm Post subject: Heartbeat acknowledgement Reply with quote

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
View user's profile Send private message
AkankshA
PostPosted: Tue Jun 17, 2014 11:16 pm Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
kiran areti
PostPosted: Wed Jun 18, 2014 12:27 am Post subject: Reply with quote

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
View user's profile Send private message
MQsysprog
PostPosted: Wed Jun 18, 2014 12:39 am Post subject: Reply with quote

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
View user's profile Send private message
JosephGramig
PostPosted: Wed Jun 18, 2014 4:41 am Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1228
Location: South 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
View user's profile Send private message AIM Address
Vitor
PostPosted: Wed Jun 18, 2014 5:02 am Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Jun 18, 2014 5:06 am Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Wed Jun 18, 2014 5:48 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9287
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
View user's profile Send private message
PaulClarke
PostPosted: Wed Jun 18, 2014 5:51 am Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
MQsysprog
PostPosted: Wed Jun 18, 2014 8:43 pm Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Wed Jun 18, 2014 9:16 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9287
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
View user's profile Send private message
Vitor
PostPosted: Thu Jun 19, 2014 5:05 am Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Thu Jun 19, 2014 7:46 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9287
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
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportHeartbeat acknowledgement
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.