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 SupportWhy these channel instances are not dropping

Post new topicReply to topic Goto page 1, 2, 3, 4  Next
Why these channel instances are not dropping View previous topic :: View next topic
Author Message
vicks_mq
PostPosted: Sun May 12, 2019 10:20 am Post subject: Why these channel instances are not dropping Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

We got these channel instances which are not dropping , we have setup the keep Alive to YES and KAINT to AUTO and HBINT to 300 seconds. so ideally the channel should drop in 5 minutes if not message arrives in that time period.

The Chanel instance has following statistics
1. current time - 12th May 14:00PM
2. last message date & time - 10th May, 17:53 PM
Bytes sent - 16744, bytes received - 16692
MCA status - Running, Substate - Receiving.
HBINT - 300, SHARECNV is 1 and discint is 0.
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Sun May 12, 2019 10:53 am Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

i just noticed that BYTSSENT BYTSRCVD count is increasing, maybe that is the reason for these channel instances not dropping.
but who could be increasing the value of BYTSSENT BYTSRCVD, as the application is not sending any messages.
Back to top
View user's profile Send private message
exerk
PostPosted: Sun May 12, 2019 12:23 pm Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6109

I assume that you have Keepalive configured within TCP/IP, and the appropriate stanza in the affected queue managers qm.ini file? Otherwise HBINT will have no effect.

Try searching the KC for an explanation of BYTSSENT/BYTSRCVD, which will give you the reason for the increasing values.

Of note, you seem to have a habit of asking questions that (in most cases) are already answered in the documentation, should you care to read it...
_________________
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
View user's profile Send private message
vicks_mq
PostPosted: Sun May 12, 2019 1:00 pm Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

exerk wrote:
I assume that you have Keepalive configured within TCP/IP, and the appropriate stanza in the affected queue managers qm.ini file? Otherwise HBINT will have no effect.
Right we have keepalive configured.

Try searching the KC for an explanation of BYTSSENT/BYTSRCVD, which will give you the reason for the increasing values.

Of note, you seem to have a habit of asking questions that (in most cases) are already answered in the documentation, should you care to read it...

Yes, it has been a roller coaster ride on MQ for me last few days, finding 75% of answers myself, seeking help on 25%
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Sun May 12, 2019 5:49 pm Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 946
Location: New Zealand

I assume that this is a CLNTCONN/SVRCONN pair of channels since you mention SHARECNV.

What makes you think the channel should 'drop' ? What are you doing to the channel to cause that ? You say that you have set DISCINT to 0. So, a SSVRCONN channel will not just drop the connection because it has not received a message for 5 minutes. Or are you killing the client ?
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
vicks_mq
PostPosted: Sun May 12, 2019 7:18 pm Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

PaulClarke wrote:
I assume that this is a CLNTCONN/SVRCONN pair of channels since you mention SHARECNV.

What makes you think the channel should 'drop' ? What are you doing to the channel to cause that ? You say that you have set DISCINT to 0. So, a SSVRCONN channel will not just drop the connection because it has not received a message for 5 minutes. Or are you killing the client ?


Hi Paul, we have around 80 instances of this particular channel running and few of them I noticed the the last message was time was 2 days old, so I was wondering no message received these last 2 days and why this channel instance is still running?
Now, consider a hypothetical scenario, if I want tthem to drop after 1 hour of no message time, what would be 1st parameter you would suggest I change?
Please note I am talking about No Message, but BYTESNT and BYTERCVD count may still increase.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Sun May 12, 2019 9:54 pm Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 946
Location: New Zealand

Hi,

Well, if you want the SVRCONN to drop a client connection because of inactivity then I would set the DISCINT parameter of the SVRCONN. Of course if the application is doing other API calls, such as opening and closing queues then the SVRCONN will not consider the client inactive even if it is not receiving messages at he moment.

Of course it goes without saying that it is better to modify your applications to disconnect at an appropriate time rather than just have the system eject them. If you find that applications are clogging up your system then your first port of call should be to talk to the application team and see whether they can change their application accordingly.

Regards,

Paul
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
hughson
PostPosted: Mon May 13, 2019 4:17 am Post subject: Reply with quote

Grand Master

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

vicks_mq wrote:
We got these channel instances which are not dropping , we have setup the keep Alive to YES and KAINT to AUTO and HBINT to 300 seconds. so ideally the channel should drop in 5 minutes if not message arrives in that time period.

The Chanel instance has following statistics
1. current time - 12th May 14:00PM
2. last message date & time - 10th May, 17:53 PM
Bytes sent - 16744, bytes received - 16692
MCA status - Running, Substate - Receiving.
HBINT - 300, SHARECNV is 1 and discint is 0.

vicks_mq wrote:
i just noticed that BYTSSENT BYTSRCVD count is increasing, maybe that is the reason for these channel instances not dropping.
but who could be increasing the value of BYTSSENT BYTSRCVD, as the application is not sending any messages.


Since you have HBINT (Heartbeat Interval) set to 300 second, this means every 5 minutes one end or other of the CLNTCONN/SVRCONN pair will send some bytes to the other end to say "Hello are you still there" and the other end (if still around) will reply to say they are. By how much are your bytes sent/rcvd increasing? If a small number, then likely to be the heartbeat flows.

Remember that CLNTCONN/SVRCONN channels are different from QMgr-QMgr channels. They do not "drop" when nothing to do like a SDR/RCVR. They only "drop" when the client application does an MQDISC, or if something happens at the network layer (e.g. a firewall boots out the socket for inactivity, or the SVRCONN cancels the comms either due to DISCINT or STOP CHANNEL command.

vicks_mq wrote:
Yes, it has been a roller coaster ride on MQ for me last few days, finding 75% of answers myself, seeking help on 25%

I don't want to poke my oar in where it is not wanted, but if you are struggling with some of the MQ concepts, would some cheap, good value MQ self-paced training be of interest? I created a number of introductory modules because I see a number of people struggling to use MQ without receiving what I would consider essential basic training. I cover all the major platforms and admin tools, and they really are good value! Check out my sig below if of interest.

Cheers,
Morag
_________________
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
vicks_mq
PostPosted: Mon May 13, 2019 5:46 am Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

hughson wrote:
vicks_mq wrote:

i just noticed that BYTSSENT BYTSRCVD count is increasing, maybe that is the reason for these channel instances not dropping.
but who could be increasing the value of BYTSSENT BYTSRCVD, as the application is not sending any messages.


Since you have HBINT (Heartbeat Interval) set to 300 second, this means every 5 minutes one end or other of the CLNTCONN/SVRCONN pair will send some bytes to the other end to say "Hello are you still there" and the other end (if still around) will reply to say they are. By how much are your bytes sent/rcvd increasing? If a small number, then likely to be the heartbeat flows.

Quote:
the number is every 300 seconds, 28 bytes are being sent.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon May 13, 2019 5:54 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8518
Location: US: west coast, almost. Otherwise, enroute.

SVRCONN channels dropping/not dropping are likely symptoms of a problem, and not the problem itself. . Sysadmins should first identify the root cause of the problem. You seem to have focused on the server end. Tells us about the client end.

Is this a new app? Has it ever worked before? What, if anything, has changed?

How are the client apps ending? With a MQDISC? With some kind of abend?
With the platform O/S failing? Client platform being rebooted?
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Mon May 13, 2019 7:49 am Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 946
Location: New Zealand

Quote:
the number is every 300 seconds, 28 bytes are being sent.


28 bytes in either direction is what you would expect for a heartbeat flow. It sounds like the channel is perfectly fine, as such I would not expect either end to drop the connection.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
vicks_mq
PostPosted: Mon May 13, 2019 7:57 am Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

PaulClarke wrote:
Quote:
the number is every 300 seconds, 28 bytes are being sent.


28 bytes in either direction is what you would expect for a heartbeat flow. It sounds like the channel is perfectly fine, as such I would not expect either end to drop the connection.

Hi Paul, so even if I changed the Discint interval to 900 seconds , that would not cause MQ to drop the connection?
The reason we are asking is there is a debate going on whether we should reduce our DISCINT from its current value of 0.
And I just want to ensure if we change DISCINT to 900 seconds that should not cause the channel instance to drop.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Mon May 13, 2019 8:03 am Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 946
Location: New Zealand

Yes, if I understand you correctly, that is correct. However, MQ comes with a lovely set of manuals and if you read the section on DISCINT it will tell you the behavior you can expect. I still think that we are advising you on a solution here rather than a problem. What is the problem you are having ? Why do you feel the need to artificially drop client connections ?
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
vicks_mq
PostPosted: Mon May 13, 2019 8:12 am Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

PaulClarke wrote:
Yes, if I understand you correctly, that is correct. However, MQ comes with a lovely set of manuals and if you read the section on DISCINT it will tell you the behavior you can expect. I still think that we are advising you on a solution here rather than a problem. What is the problem you are having ? Why do you feel the need to artificially drop client connections ?


Hi Paul, the problem we have is different MQ behaviour for the same client application running on same server. I reported the original issue on this forum
http://www.mqseries.net/phpBB2/viewtopic.php?t=76328&highlight=
I will give you a brief, when we migrated our application to MQ appliance 9, we saw the channel instances were dropping automatically after a period of inactivity(few hours). We Don' want that. we want to keep channel instances running.

now I started comparing different parameters on SVRCONN channel between our original MQ 8 LINUX and our MQ appliance.
one by one I filtered out SHARECNV,HBINT, FIREWALL TIMEOUT & KeepAlive , MAXINST, MAXINSTC and right now all these parameter are in sync between both environment.

Only diff parameter is DISCINT which is set to 3600 in new MQ appliance (where channel instances are dropping) and set to 0 in old MQ Linux(where channel instances keep running)

Just wondering if I increase the value of DISCINT in our MQ Appliance, will that change anything?
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon May 13, 2019 8:42 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8518
Location: US: west coast, almost. Otherwise, enroute.

vicks_mq wrote:
... when we migrated our application to MQ appliance 9, we saw the channel instances were dropping automatically after a period of inactivity(few hours). We Don't want that. we want to keep channel instances running.

Ok. But other than that, what other symptoms do you see? Are you/your apps missing service levels (SLAs)?

What is the expected/usual transaction rate? 50,000/second? 5,000/second? 500/second? One or two per hour?

If there is no activity on the channel hours, why would you want it to stay open?
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2, 3, 4  Next Page 1 of 4

MQSeries.net Forum IndexGeneral IBM MQ SupportWhy these channel instances are not dropping
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.