concern on MQ channel property Heartbeat interval

Question

i've got a question with channel property Heartbeat Interval(HBINT). According to the information center, it would lead channel disconnect when interval condition matures and MCA is unblocked. I made a little test in local QMGR, but i found that channel (sender-receiver) didn't change to inactive as expected. So what's the problem here? please help me out. channel definition detail is as below:

 CHANNEL(EDISONQM.GRACEQM.C1)            CHLTYPE(SDR)
 ALTDATE(2012-09-09)                     ALTTIME(11.50.52)
 BATCHHB(0)                              BATCHINT(0)
 BATCHLIM(5000)                          BATCHSZ(50)
 COMPHDR(NONE)                           COMPMSG(NONE)
 CONNAME(localhost(1414))                CONVERT(NO)
 DESCR( )                                DISCINT(300)
 HBINT(30)                               KAINT(AUTO)
 LOCLADDR( )                             LONGRTY(999999999)
 LONGTMR(1200)                           MAXMSGL(4194304)
 MCANAME( )                              MCATYPE(PROCESS)
 MCAUSER( )                              MODENAME( )
 MONCHL(QMGR)                            MSGDATA( )
 MSGEXIT( )                              NPMSPEED(FAST)
 PASSWORD( )                             PROPCTL(COMPAT)
 RCVDATA( )                              RCVEXIT( )
 RESETSEQ(NO)                            SCYDATA( )
 SCYEXIT( )                              SENDDATA( )
 SENDEXIT( )                             SEQWRAP(999999999)
 SHORTRTY(10)                            SHORTTMR(60)
 SSLCIPH( )                              SSLPEER( )
 STATCHL(QMGR)                           TPNAME( )
 TRPTYPE(TCP)                            USEDLQ(YES)
 USERID( )                               XMITQ(EDISONQM.GRACEQM.X1)

 CHANNEL(EDISONQM.GRACEQM.C1)            CHLTYPE(RCVR)
 ALTDATE(2012-09-09)                     ALTTIME(11.51.42)
 BATCHSZ(50)                             COMPHDR(NONE)
 COMPMSG(NONE)                           DESCR( )
 HBINT(30)                               KAINT(AUTO)
 MAXMSGL(4194304)                        MCAUSER( )
 MONCHL(QMGR)                            MRDATA( )
 MREXIT( )                               MRRTY(10)
 MRTMR(1000)                             MSGDATA( )
 MSGEXIT( )                              NPMSPEED(FAST)
 PUTAUT(DEF)                             RCVDATA( )
 RCVEXIT( )                              RESETSEQ(NO)
 SCYDATA( )                              SCYEXIT( )
 SENDDATA( )                             SENDEXIT( )
 SEQWRAP(999999999)                      SSLCAUTH(REQUIRED)
 SSLCIPH( )                              SSLPEER( )
 STATCHL(QMGR)                           TRPTYPE(TCP)
 USEDLQ(YES)


 C:\windows\system32>dspmqver
 Name:        WebSphere MQ
 Version:     7.1.0.1
 Level:       p710-001-120524
 BuildType:   IKAP - (Production)
 Platform:    WebSphere MQ for Windows
 Mode:        32-bit
 O/S:         Windows 7 Home Premium x64 Edition, Build 7600
 InstName:    Installation1

Thanks

Answer 1

You may wish to have a look at the Infocenter topic Checking that the other end of the channel is still available which goes into a little more detail about the algorithm that decides whether to close the channel. Specifically, at least two heartbeats must flow before the channel will disconnect so HBINT must be well less than half of DISCINT for this to take effect. Also, the channel negotiation must complete such that neither MCA derives a value of zero for HBINT.

Your post did not include a listing of the matching RCVR channel. I suspect that you did not update the HBINT there? If you display the status of the running channel you will see that on startup the channel agents negotiate the larger of their two HBINT values. So if you didn't update HBINT at the the RCVR then the running channel will have an HBINT of 300 even though you set it to 30 on the SDR.

Also, the actual timing is not exact. The intent is that the channel will time out in not less than two HBINT intervals but the actual timeout will be more than this amount. For example I set HBINT to 10 and saw the channel disconnect after about 40 seconds. Channel timeout and disconnect are intended to improve reliability of the channels and to reap orphan channels but exact timing is not as important as it would be for message or transaction processing. The idea is that if you have tons of orphan channels you would address this by fixing the broken program or by tuning timeout at a firewall rather than setting HBINT to a really low value and expecting precision. If you have a need for exact timings on channel disconnect then there's a root cause somewhere else that needs to be addressed.