|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
one SVRCONN for each client make sense? |
« View previous topic :: View next topic » |
Author |
Message
|
pcelari |
Posted: Fri Feb 28, 2020 7:55 am Post subject: one SVRCONN for each client make sense? |
|
|
Chevalier
Joined: 31 Mar 2006 Posts: 411 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 |
|
 |
Vitor |
Posted: Fri Feb 28, 2020 8:51 am Post subject: Re: one SVRCONN for each client make sense? |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 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 |
|
 |
pcelari |
Posted: Fri Feb 28, 2020 10:33 am Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006 Posts: 411 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 |
|
 |
Vitor |
Posted: Fri Feb 28, 2020 11:28 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 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 |
|
 |
pcelari |
Posted: Tue Mar 10, 2020 12:48 pm Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006 Posts: 411 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 |
|
 |
zpat |
Posted: Wed Mar 11, 2020 1:49 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 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 |
|
 |
|
|
 |
|
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
|
|
|
|