| Author |
Message
|
| smeunier |
 Posted: Thu Mar 14, 2019 11:32 am Post subject: MQ Internal Broker V6 to V9 coeexistence |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
In preparation for the eventual move off of MQ V6 (Yes, you heard that right) to MQ V9.x, I was wondering if Publications/Subscriptions on either Broker would coexist. I will try this out soon enough, but thought I would through this out first.
We have a heavy client based Pub/Sub environment running in V6. In order to do a gradual shift of applications to a newer MQ Version, I was wondering if it is feasible to connect the two QMGRS together either via manually defined channels or MQ Cluster and expect that a Publication issued in V6 would reach a subscriber in V9 environment and vis -versa?
V6 uses a different topic schema (ex THIS.IS.A.TOPIC) opposed to Post V7 brokers which recognize a topic (ex. THIS/IS/A/TOPIC) and the same for wildcards where V6(*) is a V9(#).
With these differences, would just setting PSMODE to ENABLED resolve the differences and the two Brokers could/communicate effectively? Would a client on V6 use topic structures, while the subscriber on V9 use the newer structures or will they self resolve based on the targets version? |
|
| Back to top |
|
 |
| hughson |
| Posted: Thu Mar 14, 2019 9:50 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
When MQ V7 was shipped it provided a "Queued Pub/Sub Daemon" task which runs when PSMODE(ENABLED) or PSMODE(COMPAT) is set.
This Pub/Sub Daemon task reads the SYSTEM.BROKER.* queues and replaces the MQ V6 Pub/Sub Broker and also takes over from the Message Broker is this regard also.
MQ V7+ have two wildcard schemas:-
TOPIC = Message Broker style wildcards
# = Multiple / delimited sections
+ = Single / delimited section
CHAR = MQ V6 style wildcards
* = Multiple characters
? = Single character
The topic string namespace is shared between V6 and V9 style topics, so as long as you make the subscription to the correct topic string (or topic object + topic string) in the V9 style application, then yes, you can get the messages. The topic string may not be as you initially expect though as the stream name, e.g. SYSTEM.BROKER.DEFAULT.STREAM is added to the topic string.
For Multi-queue manager topologies, you need to use the PARENT attribute on the queue manager to set up a hierarchy. A Pub/Sub cluster is not quite the same this as a MQ V6 style Pub/Sub hierarchy.
I would suggest normal channels, rather than cluster channels if you only have two queue managers,.
Read more:-Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| smeunier |
| Posted: Fri Mar 15, 2019 6:21 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Thank you Morag, this will be helpful in our march forward. |
|
| Back to top |
|
|
| smeunier |
| Posted: Wed Aug 07, 2019 7:43 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Hoping this gets seen.......
So finally we have built V9.1 Queue Managers on AIX. I have run Pub/Sub verification tests and have tested also with generic application. This works.
Rather than do a migration through all the product version levels from V6 -> 9.1, we decided to just create a V9.1 instance and do some regression testing.
Most application are using V6 jars/C libraries. They can connect to the QMGR just fine. Point to Point applications are OK. However the Pub/Sub applications are failing with a (RC2046): MQRC_OPTIONS_ERROR.
The broker is set with PSMODE(ENABLED) to cover both V6/V7 broker domain types.
I guess it was to hopeful, that the application would function asis. Not finding to much information on what to narrow in on. Thoughts? |
|
| Back to top |
|
|
| smeunier |
| Posted: Wed Aug 07, 2019 7:55 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Forgot to include the exception
| Code: |
| MAIN:ClientCollection.initialized():com.ibm.btv.clientfw.ClientCollectionException: com.ibm.btv.mqclient.MQJMSTopicsClientException: initializeJMS(): javax.jms.JMSException: MQJMS2008: failed to open MQ queue SYSTEM.BROKER.CONTROL.QUEUE LinkedException: com.ibm.mq.MQException: MQJE001: Completion Code 1, Reason 2046 |
|
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Aug 07, 2019 3:22 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Could be related to shared or exclusive access to the queue, and what other processes have it open, and their access?
_________________
Glenn |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Aug 07, 2019 3:54 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| gbaddeley wrote: |
| Could be related to shared or exclusive access to the queue, and what other processes have it open, and their access? |
I don't think shared vs exclusive access would cause an MQRC_OPTIONS_ERROR.
I would turn on activity trace on this app and see what options were actually provided on the MQOPEN. I could well imagine though that they might be something you cannot control and you'd be opening a PMR with IBM.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Aug 09, 2019 4:45 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smeunier wrote: |
Most application are using V6 jars/C libraries. They can connect to the QMGR just fine. Point to Point applications are OK. However the Pub/Sub applications are failing with a (RC2046): MQRC_OPTIONS_ERROR.
The broker is set with PSMODE(ENABLED) to cover both V6/V7 broker domain types.
|
I thought that would have been PSMODE(COMPAT).
AFAIK PSMODE(ENABLED) will only allow V7 and above type Pub/Sub.
So you would have to recompile your clients with the V9.1 client... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Sun Aug 11, 2019 2:34 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| smeunier wrote: |
Most application are using V6 jars/C libraries. They can connect to the QMGR just fine. Point to Point applications are OK. However the Pub/Sub applications are failing with a (RC2046): MQRC_OPTIONS_ERROR.
The broker is set with PSMODE(ENABLED) to cover both V6/V7 broker domain types.
|
I thought that would have been PSMODE(COMPAT).
AFAIK PSMODE(ENABLED) will only allow V7 and above type Pub/Sub.
So you would have to recompile your clients with the V9.1 client... |
PSMODE(ENABLED) is a super-set of PSMODE(COMPAT).
No recompilation of applications should be necessary. If you want to switch Pub/Sub JMS applications from the Queued Broker to the V7 Pub/Sub API you just change the ProviderVersion.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| smeunier |
| Posted: Mon Aug 12, 2019 10:44 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
In our old V6 environment, there was a single Qmgr running a broker. There were two gateway Qmgrs that shared the broker via clustering of the SYSTEM.BROKER.CONTROL.QUEUE, SYSTEM.BROKER.ADMIN.STREAM and the SYSTEM.BROKER.DEFAULT.STREAM. This allowed subscribers from the gateway queue managers to have access to the Broker without creating a hierarchy. It was a good cheap implementation.
In porting that same set up to V9.1, is when the client started getting the 2046 errors. I unclustered the SYSTEM.BROKER.CONTROL Queue, and everything started working. Working as in only on the single broker.
So it appears that clustering of the SYSTEM.BROKER.CONTROL.QUEUE is not allowed in a V9.1 environment?
This would drive me to have to set up a broker hierarchy(parent/children) if I was to keep with the multiple client entry points(connect via multiple QMGRS). Is there another way to play this out? The point of the Gateway qmgr connectivity was to offload mq connections and spread them across multiple QMGRS. Each QMGR has a maxhandles of 5000 set. |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Aug 12, 2019 2:39 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| smeunier wrote: |
| The point of the Gateway qmgr connectivity was to offload mq connections and spread them across multiple QMGRS. Each QMGR has a maxhandles of 5000 set. |
Could you achieve the same thing with some static QREMOTE definitions? Does that have the same restriction as the clustering?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Aug 13, 2019 11:14 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
 Shame on me for not thinking about the QREMOTE path!
Initial test show that Defining the SYSTEM.BROKER.CONTROL.QUEUE, SYSTEM.BROKER.ADMIN.STREAM and SYSTEM.BROKER.DEFAULT.STREAM Queues as remote simulate the clustered setup. So that is good news.
I also set up a Broker Network with two of the Queue Managers and that worked as well. At this point with only three QMGRS in a Broker Network, I'm not seeing a huge advantage. Both ways will put the focus on the Parent broker(broker network) or the sole broker, as remote queue setup. So both require the Parent or the single broker.
Redundancy is via HACMP configuration. May eventually front the Gateway connection servers with an F5 BIGIP as a load balancer.
I'm thinking Qremotes and single broker. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 13, 2019 11:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Hmm.... Did you even look at clustered topic hosts???
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Aug 14, 2019 12:04 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| Hmm.... Did you even look at clustered topic hosts??? |
He's using the queued pub/sub interface and was clustering the queue called SYSTEM.BROKER.CONTROL.QUEUE - how would clustered topic hosts help?
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 14, 2019 4:25 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hughson wrote: |
| fjb_saper wrote: |
| Hmm.... Did you even look at clustered topic hosts??? |
He's using the queued pub/sub interface and was clustering the queue called SYSTEM.BROKER.CONTROL.QUEUE - how would clustered topic hosts help? |
No need to cluster the SYSTEM.BROKER.CONTROL.QUEUE. Define the clustered topic and the publishing host in the cluster. The topic will be published in the cluster on the topic host and distributed from there to the subscribers. If you define 2 topic hosts for a specific topic in the cluster they will be load balanced...and the cluster subscriptions will be forwarded to the topic hosts. This bypasses the standard cluster on pub/sub where every qmgr in the cluster gets all the publications. Isn't that what the OP was trying to achieve by clustering the SYSTEM.BROKER.CONTROL.QUEUE?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
