| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| heatbeat in MQSVRCONN for MQ v6 vs MQ v7 |
« View previous topic :: View next topic » |
| Author |
Message
|
| yupoet |
 Posted: Mon May 07, 2012 5:12 am Post subject: heatbeat in MQSVRCONN for MQ v6 vs MQ v7 |
 |
|
Apprentice
Joined: 26 Nov 2008
Posts: 36
|
Read a sentence in MQ v7 Infocenter:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.explorer.doc%2Fe_properties_zosconfiguring.htm, search "Heartbeat interval (HBINT)"
| Quote: |
"Start of changeFor server-connection and client-connection channels working in the channel mode prior to WebSphere MQ Version 7.0, heartbeats flow only when a server MCA is waiting for an MQGET command with the WAIT option specified, which it has issued on behalf of a client application." |
Does this mean before MQ v7, SVRCONN channel, only "MQGET command with the WAIT option specified" can send out heart beats?
_________________
With warm regards and thanks! |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon May 07, 2012 5:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Prior to MQ v7, an existing clntconn/svrconn channel would not send any traffic along it unless the application was actually using the channel. The only time it would make any effort to keep the channel alive by sending heartbeats was when it was delayed expecting a response. |
|
| Back to top |
|
|
| yupoet |
| Posted: Mon May 07, 2012 8:21 am Post subject: |
|
|
Apprentice
Joined: 26 Nov 2008
Posts: 36
|
In this case, suppose there is a MQ AIX v6, a server connection channel is there, the client could not keep it alive if just only putting message into the queue, unless it do a MQGET with WAIT option?
Is it possible to make the SVRCONN (MQ v6) channel to be running always?
_________________
With warm regards and thanks! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 07, 2012 8:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
EDIT: scratch that last response.
Regardless, a client application needs to detect that a connection has failed and make a reasonable determination about whether or not to reconnect.
You can also take various kinds of steps at the network and OS layers to ensure that connections aren't closed willy nilly just because they don't happen to be sending heartbeats. |
|
| 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
|
|
|
|
