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 SupportHow to verify HBINT is indeed sending heartbeat packets

Post new topicReply to topic
How to verify HBINT is indeed sending heartbeat packets View previous topic :: View next topic
Author Message
jaswant.bea979
PostPosted: Mon Mar 26, 2018 7:49 am Post subject: How to verify HBINT is indeed sending heartbeat packets Reply with quote

Novice

Joined: 15 Mar 2018
Posts: 16

Hi,

Flow:
App (using CCDT) > f5 > Active node of MQ 8 ( Multi instance QM)

SVRCONN Details:
Code:

   CHANNEL(PAY.CLIENT)                  CHLTYPE(SVRCONN)
   ALTDATE(2018-01-29)                     ALTTIME(16.32.27)
   CERTLABL( )                             COMPHDR(NONE)
   COMPMSG(NONE)                           DESCR( )
   DISCINT(0)                              HBINT(300)
   KAINT(AUTO)                             MAXINST(999999999)
   MAXINSTC(999999999)                     MAXMSGL(4194304)
   MCAUSER(gcuppapl)                       MONCHL(QMGR)
   RCVDATA( )                              RCVEXIT( )
   SCYDATA( )                              SCYEXIT( )
   SENDDATA( )                             SENDEXIT( )
   SHARECNV(10)                            SSLCAUTH(REQUIRED)
   SSLCIPH( )                              SSLPEER( )
   TRPTYPE(TCP)


Issue - SVRCONN goes to INACTIVE.

I would like to keep SVRCONN Channel running all the time. To achieve this DISCINT is set to zero. Still it goes to INACTIVE. To re-establish the connection , app restart is required.

Questions:

How to keep SVRCONN up all the time?
HBINT is set to 300 secs and looks like it not helping. How can I check if indeed heartbeat packets are flowing through the channel ? Reason I ask is if I change DISCINT to ,say , 6000 . I would need a way to verify HBINT is flowing.

Thank you
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Mar 26, 2018 8:15 am Post subject: Re: How to verify HBINT is indeed sending heartbeat packets Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25051
Location: Ohio, USA

jaswant.bea979 wrote:
I would like to keep SVRCONN Channel running all the time.


Why? Is it because of:

jaswant.bea979 wrote:
To re-establish the connection , app restart is required.


Having the SVCONN running will not fix this. A client SVRCONN is not like a queue manager to queue manager connection, where it's either running, inactive or stopped. Whatever the application is doing to hose up the specific SVRCONN instance that it spawned from the administratively defined one will occur no matter the status of the administratively defined channel.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
jaswant.bea979
PostPosted: Mon Mar 26, 2018 9:16 am Post subject: Reply with quote

Novice

Joined: 15 Mar 2018
Posts: 16

Thank you and quick question.
Is there a way to automatically start the SVRCONN channel?

Like SDR channel, where , if trigger is ON , INITQ is set at transmission queue and t channel started with the name of INITQ (runmqchi -m QM1 -q INITQ -r)
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Mar 26, 2018 9:48 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25051
Location: Ohio, USA

jaswant.bea979 wrote:
Is there a way to automatically start the SVRCONN channel?


No, because there's no concept of an SVRCONN channel "starting".

jaswant.bea979 wrote:
Like SDR channel, where , if trigger is ON , INITQ is set at transmission queue and t channel started with the name of INITQ (runmqchi -m QM1 -q INITQ -r)


Vitor wrote:
A client SVRCONN is not like a queue manager to queue manager connection, where it's either running, inactive or stopped

_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
hughson
PostPosted: Mon Mar 26, 2018 2:00 pm Post subject: Re: How to verify HBINT is indeed sending heartbeat packets Reply with quote

Shaman

Joined: 09 May 2013
Posts: 775
Location: Bay of Plenty, New Zealand

jaswant.bea979 wrote:
Questions:
How to keep SVRCONN up all the time?
HBINT is set to 300 secs and looks like it not helping. How can I check if indeed heartbeat packets are flowing through the channel ? Reason I ask is if I change DISCINT to ,say , 6000 . I would need a way to verify HBINT is flowing.

Answers:
A SVRCONN channel is ONLY running when the client connection application is running. When the application disconnects, the SVRCONN stops. You cannot have the SVRCONN running without the application. An an MQ administrator your job should be to ensure the SVRCONN is in a position where it is able to start when called upon by the application, which means ensuring it is INACTIVE rather than STOPPED. You cannot however, keep it in RUNNING status without the application.

If you want to check that heartbeat packets are flowing during a period when the application is connected but idle (i.e. not sending any data itself) then you can look at the output of the following command:
Code:
DISPLAY CHSTATUS(channel-name) ALL

and look at the number of bytes sent and received.

Cheers,
Morag

P.S. If you'd like to learn more about client applications and SVRCONNs and how they work, may I suggest you try our MQ training modules (see link in my sig below). There is one dedicated to clients.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
jaswant.bea979
PostPosted: Wed Mar 28, 2018 10:34 am Post subject: Reply with quote

Novice

Joined: 15 Mar 2018
Posts: 16

Thank you Morag for your answer especially for heart beat part.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Mar 28, 2018 8:10 pm Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19702
Location: LI,NY

And don't forget to make sure that the heartbeat of both server connection and client connection channel is under the timeout of the firewall for an idle connection.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
jaswant.bea979
PostPosted: Thu Mar 29, 2018 7:05 am Post subject: Reply with quote

Novice

Joined: 15 Mar 2018
Posts: 16

Thank you fjb_saper. Just sharing.... I recently ran into this situation where connectivity to ACTIVE node was getting dropped even all timeouts were under heartbeat interval and found KEEP-ALIVE was missing at LB and enabling it fixed the issue. This was happening with a new setup of MQ Version 8 and load balancer is F5.

The issue was identified by Support using the packet trace.
Command to start taking trace:
strmqtrc -m QMGR_NAME -t detail -t all
dspmqtrc * (creates .FMT files) #
Back to top
View user's profile Send private message
mvic
PostPosted: Thu Mar 29, 2018 3:00 pm Post subject: Reply with quote

Jedi

Joined: 09 Mar 2004
Posts: 2046

Quote:
Issue - SVRCONN goes to INACTIVE.

Is that actually a problem?
I think, probably not.
Your last post says that connections were being dropped, and something related to TCP keepalive helped you. But TCP keepalive is useful mainly (only?) for ensuring that connections that have dropped, are noticed sooner rather than later.
Back to top
View user's profile Send private message
jaswant.bea979
PostPosted: Thu Mar 29, 2018 5:06 pm Post subject: Reply with quote

Novice

Joined: 15 Mar 2018
Posts: 16

It not a problem but everyone ( at my work ) is interested if app restart is required then why not leave channel RUNNING. I tried to convince everyone and next question was if app is suppose to start the communication then it has to be MQ Client which initiates the connection and app is just using the MQ client. Yup it was Dev team.

For keep alive , I was told keep alive in F5 is different than IBM MQ definition.
F5 sits in middle and works as proxy .That is app opens a connection to LB and LB initiates another connection and keeps a "connection pool".If keep alive is enabled LB reuses the same connection, already established TCP connection , for next request sent by application.

Assuming idle TCP timeout is 600 secs ( more than DISCINT=300 secs) at LB so this timeout shouldnt play any role but it does.
If keep-alive is not enabled, reuse of existing connection won't occur for new incoming requests and LB will create new connections to MQ . Existing old connection is just going to tied to LB and that may become stale and eventually terminated by LB which appeared on MQ log saying "peer terminated the connection".

This was the explanation by LB team. I hope i got it right
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Mar 29, 2018 8:07 pm Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19702
Location: LI,NY

Thanks for the explanation. Such a connection at the LB is usually called a "sticky" connection... and yes this is the way that connections to MQ should work on a Load Balancer. I guess the mention of keep-alive through us a little bit because we are more used to applying it to a different context
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportHow to verify HBINT is indeed sending heartbeat packets
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.