|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Keepalive and Heartbeat interval - what is different? |
« View previous topic :: View next topic » |
Author |
Message
|
KAKEZ |
Posted: Sun Nov 24, 2002 10:35 pm Post subject: Keepalive and Heartbeat interval - what is different? |
|
|
Centurion
Joined: 10 Oct 2002 Posts: 117
|
Hi,
can somebody explain me clearly what are exactly the differences betwen them?
and when they are to be used ?
thanks a lot
Jack |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Nov 27, 2002 5:24 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
To the best of my knowledge, they both accomplish the same thing. They both send data back and forth during periods of channel inactivity. If either side of a channel does not get a HB or KA packet from the other side within the interval, the channel assumes a network outage and puts the channel into an Inactive state, ready to be restarted when more messages arrive.
Without one of these 2 methods, a RCVR can be left in a permanent state of RUNNING, waiting for messages from a SNDR over a network connection that is no longer there. When the network does come back up, the RCVR is still stuck on waiting for the previous socket signature.
ADOPTMCA allows the SNDR to tell the other side to give up waiting on that old instance and try the new one it is sending at the moment.
I guess Keep Alive is only valid for TCP, while Heartbeats work for TCP and other transmission protocals as well. I think you can get everything you need from using DISCINT, Heartbeats and AdooptMCA, and just leave Keep Alive at a high enough value so that it doesn't interfere with Heartbeats.
Hopefully, someone can give a better answer of why someone would use Keep Alive? Seems to me its redundant if Heartbeat is available.
Maybe its like Channel Conversion. It used to be needed back in the day when some Queue Managers did not support conversion, and you needed to convert the message before sending it to those guys. Now, it is pretty much useless, but still there. Maybe Keep Alive was more valuable before Heartbeat was introduced??? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
KAKEZ |
Posted: Thu Nov 28, 2002 10:37 pm Post subject: Keepalive |
|
|
Centurion
Joined: 10 Oct 2002 Posts: 117
|
Thanks a lot Peter for your clear explanations
Jack |
|
Back to top |
|
 |
matthews |
Posted: Fri Nov 29, 2002 6:44 pm Post subject: KeepAlive vs heartbeat |
|
|
 Novice
Joined: 15 Apr 2002 Posts: 12
|
I would add the following to Peter's description. The support for Keepalive, which is a TCP/IP provided function was added before Heartbeat (which is handled exclusively by MQ). The downside to keepalive is that it's delay value is set on the platform and cannot be controlled by an application. Default values for keepalive tend to be too large for use with MQ. Its main effect was to help break the Receiver channel out of its "blocked receive".
On the other hand, Heartbeat is controlled by MQ and negotiated when the channel starts. The receiver channel "knows" that the connection to the sender is gone after a certain number of heartbeat intervals pass without and communications (the number differs between releases but is in the general range of 2 to 3). Along about the time that the ADOPTMCA (and ADOPTNEWMCA) were added to MQ (via CSD and PTF), the receiver channel was changed to use an "unblocked accept" to make recovery easier.
You should always use the Heartbeat interval. I would not expect that Keepalive would any any negative impact if used. I would also strongly encourage the use of ADOPTMCA to give all the help possible for channel recovery. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Dec 02, 2002 7:13 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Some more info.
Keep Alive is configured at the Server level, so all applications, MQ included, have to agree on a particular value. (On z/OS, at version 5.3, Keep Alive is configurable at the channel level (the KAINT channel attribute).) The default value on most systems is 2 hours, which is not that useful for us in MQ land.
Now there is one place where Keep Alive works where Heartbeats don't. When an MQClient connects in via a SRVRCONN channel, heartbeats only flow to and from the Client/Server during an MQGET with wait. All other times there is no code on the Client side to heartbeat back, so the SVRCONN doesn't even bother. In these cases, Keep Alive can kick in and detect a Client app that left without issuing MQDISC.
For Heartbeat, the larger of 2 sides is used. Zero is considred no Heartbeat at all, and is considered the "biggest" number. In other words if you are communicating with another company, and they refuse to set alter their HB, you are stuck with what they have if the # is bigger, even 0. Keep Alive can act as a back up in these cases.
Heartbeat require that the other side heartbeat back. This means the other side needs a running application, the MCA, to be alive. Compare this to Keep Alive, where it only checks for the presence of a live socket on the other side. The corresponding process may in fact be hung. In this regard, heartbeat is a little more robust in seeing what is really going on.
Thanks to the guys at Hursley IBM for providing this additional info to me. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
KAKEZ |
Posted: Mon Dec 02, 2002 10:22 pm Post subject: Keepalive and Heartbeat |
|
|
Centurion
Joined: 10 Oct 2002 Posts: 117
|
Thanks to all for this very detailed information - very interesting indeed!
Jack
 |
|
Back to top |
|
 |
anh |
Posted: Sun Jun 24, 2012 11:04 pm Post subject: |
|
|
Newbie
Joined: 03 Jan 2012 Posts: 3
|
Thanks Pete for the info!
In WMQ v7, HBINT works well with server-connection and client-connection channels. So is there any other cases that KAINT works but HBINT doesn't?
Quote: |
Now there is one place where Keep Alive works where Heartbeats don't. When an MQClient connects in via a SRVRCONN channel, heartbeats only flow to and from the Client/Server during an MQGET with wait. All other times there is no code on the Client side to heartbeat back, so the SVRCONN doesn't even bother. In these cases, Keep Alive can kick in and detect a Client app that left without issuing MQDISC. |
|
|
Back to top |
|
 |
exerk |
Posted: Mon Jun 25, 2012 12:15 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
anh wrote: |
Thanks Pete for the info!
In WMQ v7, HBINT works well with server-connection and client-connection channels. So is there any other cases that KAINT works but HBINT doesn't?
Quote: |
Now there is one place where Keep Alive works where Heartbeats don't. When an MQClient connects in via a SRVRCONN channel, heartbeats only flow to and from the Client/Server during an MQGET with wait. All other times there is no code on the Client side to heartbeat back, so the SVRCONN doesn't even bother. In these cases, Keep Alive can kick in and detect a Client app that left without issuing MQDISC. |
|
Please do not re-open 10 year old posts. Better to start a new one and refer back to the original post. Thank you. _________________ 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: Mon Jun 25, 2012 3:35 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
anh wrote: |
Thanks Pete for the info!  |
Quote: |
Posted: Mon Dec 02, 2002 10:22 pm Post subject: Keepalive and Heartbeat |
While the information found in this particular 10 year old post may be accurate, it likely reflects 10 year old versions of MQ and TCP.
I tend to doubt all decade-old posts. _________________ 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 |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|