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 Supportone SVRCONN for each client make sense?

Post new topicReply to topic
one SVRCONN for each client make sense? View previous topic :: View next topic
Author Message
pcelari
PostPosted: Fri Feb 28, 2020 7:55 am Post subject: one SVRCONN for each client make sense? Reply with quote

Partisan

Joined: 31 Mar 2006
Posts: 375
Location: New York

Greetings...

In the past, when I setup mqclient channels for applications, I typically create one channel for each application group. This seems to keep the number of svrconn channels under control while maintaining a sort of separation. But even then I doubted if it was necessary so, as a single svrconn channel can serve all clients connected to a single qmgr.

In a new assignment site, the organization setup one svrconn channel for each client, and there're hundreds of them, even though they all access the same queues. The reason, I was told, was ease of trouble-shooting - "we can simply manually stop the channel if there is a problem with a particular client during trouble-shooting.

I believe this is actually not necessary, as it is not difficult to identify the offending client just by digging a bit in the instance status. But I'm not sure if this little inconvenience makes it impractical.

Would someone share some insight about best practice over this subjects?

thanks so much!
_________________
pcelari
-----------------------------------------
- a master of always being a newbie
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Feb 28, 2020 8:51 am Post subject: Re: one SVRCONN for each client make sense? Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25974
Location: Texas, USA

pcelari wrote:
Would someone share some insight about best practice over this subjects?


My 2 cents:

The "best practice" is to have enough channels that you can separate, isolate and control the applications. Assume in all cases that you can't control a rogue or misbehaving applications (for discussion, assume an application that's stuck in some sort of loop and flooding the queue manager with messages); even if you can identify the application in the way you describe, there could be a serious lag between that identification and getting someone to issue a kill -9 on a prod box. So you're left with stopping the channel it's using.

You don't want a single channel, because that will bring the business to a crashing halt. You want to limit the collateral damage to innocent bystander applications and there may be a logical grouping of applications round a single channel.

This brings up the other aspect of control; the administration of the channels. If you have sufficient automation, it's possible to have one channel per application (and my current site does exactly that). It allows granual control of the applications, and allows us to use SSL in whatever weird and crazy ways the security people want. If you don't have a solid automation strategy, then on an estate of any size the number of channels would proliferate out of your control quite quickly so you'd want to use the grouping I mention above.

Certainly "how many client channels should I have?" is another example of there being no right answer that can be expressed an an integer.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
pcelari
PostPosted: Fri Feb 28, 2020 10:33 am Post subject: Reply with quote

Partisan

Joined: 31 Mar 2006
Posts: 375
Location: New York

Hi Vitor, thanks for sharing your valuable insight!

You're right, I used to do manual killing of the svrconn instance that was hanging with no activity when an application owner called for issue. But then I had just a few channels to do such, and over-time I could educate our developers to properly disconnect after putting messages. That's when such needs rarely arise.

But with hundreds of external clients, such would be impossible. I definitely would strive the route you pointed to - automate such handling instead of manual intervention.
_________________
pcelari
-----------------------------------------
- a master of always being a newbie
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Feb 28, 2020 11:28 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25974
Location: Texas, USA

pcelari wrote:
over-time I could educate our developers




pcelari wrote:
That's when such needs rarely arise.


Also why I quoted the example I did. Even with a group of educated developers (and those are two words I seldom put next to each other), the biggest problem for an admin is not a channel hanging with no activity (because that's typically a problem for the application as you point out) but is an application that's gone contact admin and is trying to run your queue manager out of resources. The first case is something you can sort out within the SLA for dealing with such things and if the application drops out of SLA, well it sucks to be them.

The queue manager running out of resource will affect all applications eventually and will affect your SLA (by implication including bonus payment, yearly reviews, and standing within the organization) quickly. Hence firm, rapid and decisive action is needed to prevent these issues or worse, one of those interminable conference calls with huge numbers of senior managers, none of whom understand the problem or have anything to offer in terms of resolution but all have to have their say on what they think the problem is, the impact it's having, how it should have been prevented and what should be done to prevent it in the future.

pcelari wrote:
But with hundreds of external clients, such would be impossible. I definitely would strive the route you pointed to - automate such handling instead of manual intervention.


Not the place for automation. Shutting down a channel (especially in the educated environment you describe) should be so infrequent as to be handled manually. The biggest bang for your buck is to automate the provisioning of the new channels as part of the application being on-boarded to your queue manager; this is a frequent occurrence and gives you both the benefits of consistency & freedom from humdrum.



Educated developers? Oh the bliss......
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
pcelari
PostPosted: Tue Mar 10, 2020 12:48 pm Post subject: Reply with quote

Partisan

Joined: 31 Mar 2006
Posts: 375
Location: New York

Quote:
but is an application that's gone contact admin and is trying to run your queue manager out of resources.


thanks for pointing this out Vitor. This is actually the case I encountered quite often before. So as you illustrated, we need to find the right balance.

thanks a lot for that hell lot of insights!


_________________
pcelari
-----------------------------------------
- a master of always being a newbie
Back to top
View user's profile Send private message
zpat
PostPosted: Wed Mar 11, 2020 1:49 pm Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5692
Location: UK

Use MAXINSTC and MAXINST to control SVRCONN usage.

Stopping server conn channels has never given me anything but grief so I try not to do it, better to stop the application or reboot that server.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ Supportone SVRCONN for each client make sense?
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.