| Author |
Message
|
| saviobarr |
 Posted: Fri Mar 23, 2018 12:54 pm Post subject: IIB Node connected to multiple QMGRs |
 |
|
Centurion
Joined: 21 Oct 2014
Posts: 100
Location: Sao Paulo, Brazil
|
|
| Back to top |
|
 |
| mpong |
| Posted: Fri Mar 23, 2018 7:28 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2010
Posts: 164
|
| What version of IIB are you using? Did you look at the MQConnection property of MQ nodes in any version of IIB 10? |
|
| Back to top |
|
|
| saviobarr |
| Posted: Sat Mar 24, 2018 12:04 am Post subject: |
|
|
Centurion
Joined: 21 Oct 2014
Posts: 100
Location: Sao Paulo, Brazil
|
| mpong wrote: |
| What version of IIB are you using? Did you look at the MQConnection property of MQ nodes in any version of IIB 10? |
Version 10.
_________________
Go as far as you can go. Then go farther! |
|
| Back to top |
|
|
| saviobarr |
| Posted: Mon Mar 26, 2018 6:06 am Post subject: |
|
|
Centurion
Joined: 21 Oct 2014
Posts: 100
Location: Sao Paulo, Brazil
|
| Quote: |
| Did you look at the MQConnection property of MQ nodes in any version of IIB 10? |
Is that behavior achieved by setting these properties?
_________________
Go as far as you can go. Then go farther! |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Mon Mar 26, 2018 6:57 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
Hi Savio,
Regarding your query
| Quote: |
| how is it possible to have more than one QMGR on an Integration Node? |
I don't think it is possible for IIB to have multiple 'local queue manager' as such but you can get IIB to talk to multiple local Qmgrs and remote QMgrs via combination of the default qmgr connection and via client connections.
For eg:- referring to the IBM example, you can configure one MQInput node to connect to QMGR1 (assume this one as IIB's local qmgr), another MQInput node to talk to QMGR2 running on the same server via client mode and an MQOutput node to send messages to QMGR3 (a remote qmgr) again via client mode. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Mar 26, 2018 7:06 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
However - do not go around connecting point to point via client mode unless there is a very good reason.
Sending all messages via your "local" QMGR (as was perfectly adequate for the first 18 years of IIB's life) is generally preferable.
Why use client mode if you have a local QM?
1. Doesn't know any better.
2. Want to create synchronous co-dependencies on other QMs.
3. See (1).
_________________
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 |
|
|
| Vitor |
| Posted: Mon Mar 26, 2018 7:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Why use client mode if you have a local QM? |
Because you can save some PVUs and align IIB with other MQ-aware applications that huddle round a hub queue manager rather than having one specific to IIB. I accept that you could use the previous version queue manager as such a hub, but it does confuse and confound the topology, gives you cross dependencies, cross maintenance people and so forth.
I certainly concur that you shouldn't just client IIB onto every queue manager in your estate and use it as a message hub. More traditional queue manager to queue manager topologies are time tested and true for such use cases.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Mar 27, 2018 2:38 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I refer the honourable gentleman to my previous answer, if you already have a local QMGR for the broker, your arguments don't really apply.
I can see some cases for not having a local queue manager on the broker host (although you lose some key broker functions).
However point to point MQ connections will be a support challenge and I can foresee configuration errors causing havoc. In my experience, if a developer/deployer can get it wrong - they will.
If you were to nominate a hub qmgr on another host as the primary one for the broker - this would reduce the risk of anarchy. However it might also reduce transactional integrity.
For asynchronous traffic using a client connection to the target QM makes the broker flow dependent on the target QM being available whenever needed and not using the store and forward capability of MQ.
Expect broker support callouts whenever one of these non-broker QMs goes down for any reason causing flows to fail.
_________________
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 |
|
|
| Vitor |
| Posted: Tue Mar 27, 2018 5:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| I refer the honourable gentleman to my previous answer, if you already have a local QMGR for the broker, your arguments don't really apply. |
They apply to me, because we're deliberately removing the local queue manager used by our IIBv9 installations when they're upgraded to IIBv10, and using our hubs. The use of a local queue manager for v10 will be an exception, paid for by the development team that wants to use a function in their flow that requires a local queue manager on v10.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 27, 2018 5:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| zpat wrote: |
| I refer the honourable gentleman to my previous answer, if you already have a local QMGR for the broker, your arguments don't really apply. |
They apply to me, because we're deliberately removing the local queue manager used by our IIBv9 installations when they're upgraded to IIBv10, and using our hubs. The use of a local queue manager for v10 will be an exception, paid for by the development team that wants to use a function in their flow that requires a local queue manager on v10. |
What will they pay for? The license for a local copy of MQ on the IIB server is included in the IIB license.
If its funny-money company-bucks to cover the additional administration of another queue manager, OK, I get that. But there are no PVUs to save by avoiding the local QM.
Has there been any (legitimate) concerns or issues with performance for the flows that now need to make MQ Client API calls?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 28, 2018 5:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| What will they pay for? The license for a local copy of MQ on the IIB server is included in the IIB license. |
Shush.......
| PeterPotkay wrote: |
| If its funny-money company-bucks to cover the additional administration of another queue manager, OK, I get that. |
| PeterPotkay wrote: |
| But there are no PVUs to save by avoiding the local QM |
If our application people find out, I'm holding you accountable.
| PeterPotkay wrote: |
| Has there been any (legitimate) concerns or issues with performance for the flows that now need to make MQ Client API calls? |
None of our testing has indicated this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Wed Mar 28, 2018 5:43 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 28, 2018 5:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Yeah, and application developers read the InfoCenter 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
