|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
![Reply to topic](templates/DAJ_Glass/images/lang_english/reply.gif) |
|
Channels, when to share, when not to share |
« View previous topic :: View next topic » |
Author |
Message
|
fswarbrick |
Posted: Tue Sep 17, 2019 12:24 pm Post subject: Channels, when to share, when not to share |
|
|
Apprentice
Joined: 07 Jul 2014 Posts: 42
|
So we're a very small user of MQ, and we don't truly have an expert. My question is around MQI channels and if they should be "shared" by multiple clients, or if each client should have a unique channel. For example, in our dev/test/cert environment we have the same application running on multiple servers. Whoever decided on how to set up the channels decided that each server should have its own dedicated channel. On the other hand, for the next application all of the servers connect using the same channel. The channel is named after the application, but is not "segregated" by server.
Now that we're adding a third MQ using application I'm having trouble finding any good guidance on the matter. I'm interested in your thoughts. Thanks! |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
RogerLacroix |
Posted: Tue Sep 17, 2019 1:03 pm Post subject: |
|
|
![](images/avatars/136281076646ca0b3d89dee.gif) Jedi Knight
Joined: 15 May 2001 Posts: 3253 Location: London, ON Canada
|
From a support point of view, it is far better for each application to have their own channel. Hence, if you ever have a problem with the application, you can stop the channel without affecting other applications connecting to the queue manager.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
fswarbrick |
Posted: Tue Sep 17, 2019 1:09 pm Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014 Posts: 42
|
RogerLacroix wrote: |
From a support point of view, it is far better for each application to have their own channel. Hence, if you ever have a problem with the application, you can stop the channel without affecting other applications connecting to the queue manager.
Regards,
Roger Lacroix
Capitalware Inc. |
That makes sense.
If the same application is, say, load balanced to several servers, its OK for them all to use the same channel? |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
RogerLacroix |
Posted: Tue Sep 17, 2019 1:12 pm Post subject: |
|
|
![](images/avatars/136281076646ca0b3d89dee.gif) Jedi Knight
Joined: 15 May 2001 Posts: 3253 Location: London, ON Canada
|
fswarbrick wrote: |
If the same application is, say, load balanced to several servers, its OK for them all to use the same channel? |
Do you mean MI queue managers or between different clustered queue managers? You should have the same application setup across each unique MQ environment. i.e. DEV/QA/UAT/PROD
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
fswarbrick |
Posted: Tue Sep 17, 2019 2:08 pm Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014 Posts: 42
|
RogerLacroix wrote: |
fswarbrick wrote: |
If the same application is, say, load balanced to several servers, its OK for them all to use the same channel? |
Do you mean MI queue managers or between different clustered queue managers? You should have the same application setup across each unique MQ environment. i.e. DEV/QA/UAT/PROD |
One queue manager per environment, but multiple servers running the same application connecting to each QM. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
gbaddeley |
Posted: Tue Sep 17, 2019 3:56 pm Post subject: |
|
|
![](images/avatars/gallery/Star Wars/movie_star_wars_yoda.gif) Jedi
Joined: 25 Mar 2003 Posts: 2495 Location: Melbourne, Australia
|
fswarbrick wrote: |
RogerLacroix wrote: |
From a support point of view, it is far better for each application to have their own channel. Hence, if you ever have a problem with the application, you can stop the channel without affecting other applications connecting to the queue manager.
Regards,
Roger Lacroix
Capitalware Inc. |
That makes sense.
If the same application is, say, load balanced to several servers, its OK for them all to use the same channel? |
If an app environment has load balanced MQ client connections across several different MQ queue managers, its normal and most practical to use the same channel name.
I agree with Roger, its standard best practice for each app to have their own MQI channel name.
Also, the name can include the environment. This lessens the chance that an app accidentally connects to the wrong environment. eg. MYAPP.DEV.SVRCONN, MYAPP.PROD.SVRCONN
A 20 character limit applies. '.SVRCONN' is actually superfluous, so can be left out, or appreviated to '.CL' or similar meaningful suffix. _________________ Glenn |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
HubertKleinmanns |
Posted: Wed Sep 18, 2019 2:24 am Post subject: |
|
|
![](images/avatars/c2ddd3b643e1be86dfb62.gif) Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
fswarbrick wrote: |
RogerLacroix wrote: |
fswarbrick wrote: |
If the same application is, say, load balanced to several servers, its OK for them all to use the same channel? |
Do you mean MI queue managers or between different clustered queue managers? You should have the same application setup across each unique MQ environment. i.e. DEV/QA/UAT/PROD |
One queue manager per environment, but multiple servers running the same application connecting to each QM. |
Serveral app servers connecting to the same QMgr may share the same channel. But you should think about the no. of channel instances. On distributed QMgrs the channels are limited too 100 active at the same time (total across all channel names). You shoudl think about
- increasing this number (in "qm.ini")
- limit the instances on channel base (using Attribute MAXINST)
- limit the instances on server/IP base (using Attribute MAXCINST) _________________ Regards
Hubert |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
fswarbrick |
Posted: Wed Sep 18, 2019 8:16 am Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014 Posts: 42
|
Thanks all. I have options to consider. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Sep 18, 2019 11:24 am Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9403 Location: US: west coast, almost. Otherwise, enroute.
|
HubertKleinmanns wrote: |
- limit the instances on server/IP base (using Attribute MAXCINST) |
MAXINSTC limits the maximum instances of the channel from an individual client. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
HubertKleinmanns |
Posted: Thu Sep 19, 2019 2:24 am Post subject: |
|
|
![](images/avatars/c2ddd3b643e1be86dfb62.gif) Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
bruce2359 wrote: |
HubertKleinmanns wrote: |
- limit the instances on server/IP base (using Attribute MAXCINST) |
MAXINSTC limits the maximum instances of the channel from an individual client. |
1. You are correct, the Name is MAXINSTC, not MAXCINST (my fault).
2. An "individual client" means "individual IP" - MQ doesn't distinguish apps which come from the same IP (e. g. MQ Explorer and MQMON). _________________ Regards
Hubert |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
|
|
![Reply to topic](templates/DAJ_Glass/images/lang_english/reply.gif) |
|
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
|
|
|
|