| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| IIB 9 and IIB 10 Co existence with single MQ Queue Manager |
« View previous topic :: View next topic » |
| Author |
Message
|
| DeadPool |
 Posted: Mon Jun 19, 2017 12:34 am Post subject: IIB 9 and IIB 10 Co existence with single MQ Queue Manager |
 |
|
Apprentice
Joined: 27 May 2016
Posts: 30
|
OK guys n gals
We all know that differing versions of IIB / Broker / WMB whatever you call it these days can be installed side by side and co exist fine with separate queue managers etc however,
picture yourself on a journey beyond sight and sound you've left your normal world behind and entered the twilight zone
currently we are running IIB 9.0.0.7 with mq 8.0.0.5 on aix all working fine no issues.
we are looking at upgrading to IIB 10.0.0.8 to take advantage of teh REST functionality within this version.
I have it in my head that instead of creating new environments for 10.0.0.8 etc we can install it on teh existing environments which is no big deal HOWEVER with the ability in IIB to run without a queue manager or at least a remote one, I am thinking taht we could utilise the existing MQ infrastructure. By this I mean install 10 side by side with 9 and have both IIB installs running on same MQ Queue Manager.
Obviously some objects would need to be separated by name to ensure messages went through correct version of IIB BUT I cannot think we this would not work
Can anyone here think of a reason why this could not be instigated?
Cheers |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Jun 19, 2017 2:29 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
You need to check whether the use of MQ by IIB nodes such as aggregation, re-sequence etc, can use a "remote" QM.
I suspect not, so what you intend to do means that any constraints in the use of IIB nodes without a local QM will still apply.
Personally, I have never understood why WMB/IIB did not simply use a broker specific prefix on all their internal queues, thus allowing sharing of QMs from day one.
| Quote: |
The following IBM Integration Bus features require WebSphere MQ Server to be installed on the same machine as the integration node, and they are available for use only if you specify a queue manager on the integration node:
•Record and replay
•Global transactionality
•Event-driven processing nodes (aggregate, collector, sequence, resequence, and timeout nodes)
•FTEInput and FTEOutput nodes
•CDInput and CDOutput nodes
•SCA nodes (with MQ bindings)
•Integration nodes with HTTP listeners
•HTTP proxy servlet
•High availability configurations
The integration node listener requires access to WebSphere MQ Server, so you must install it if you want to use an integration node listener to manage HTTP messages in your HTTP or SOAP flows. However, if you use HTTP nodes or SOAP nodes with the integration server embedded listener, they do not require access to WebSphere MQ. |
_________________
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 |
|
|
| DeadPool |
| Posted: Mon Jun 19, 2017 3:29 am Post subject: |
|
|
Apprentice
Joined: 27 May 2016
Posts: 30
|
zpat thanks for that it confirmed my thoughts
The 2 instances of IIB will be on teh same lpar but where IIB 9 already has a QM on same lapr I am thinking we just install IIB and point it at the QM for IIB 9
AS you say naming convention can ensure only certain queues are available to each IIB instance.
I suppose I phrased my question slightly wrong what I meant to say was
Is there any reason why I cannot do the above ie use existing on same lpar MQ infrastructure |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Jun 19, 2017 5:09 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
I have answered this question.
IBM have not used a naming convention to isolate broker system queues so you cannot share a QM over two brokers if you use any of the features above which use MQ internally.
A strange oversight by IBM in my view.
_________________
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 |
|
|
| rekarm01 |
| Posted: Mon Jun 19, 2017 1:30 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| zpat wrote: |
| Personally, I have never understood why WMB/IIB did not simply use a broker specific prefix on all their internal queues, thus allowing sharing of QMs from day one. |
Out of curiousity, what would the broker specific prefix be? Would it be the broker name, or something else?
Using the broker name directly could cause some problems. Queue names are limited to 48 characters, so the broker name would have to be short enough to prevent the rest of the queue name from being truncated. And the characters allowed in a queue name are limited to a subset of the ASCII character set, so the broker name couldn't use any other characters, such as non-ASCII letters and digits, or other punctuation. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Jun 19, 2017 10:48 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
It could be (optionally) set when creating the broker in a similar way to other broker values. Not exactly a difficult problem to solve.
_________________
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
|
|
|
|
