ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportMQ Internal Broker V6 to V9 coeexistence

Post new topicReply to topic Goto page 1, 2  Next
MQ Internal Broker V6 to V9 coeexistence View previous topic :: View next topic
Author Message
smeunier
PostPosted: Thu Mar 14, 2019 11:32 am Post subject: MQ Internal Broker V6 to V9 coeexistence Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 301

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
View user's profile Send private message
hughson
PostPosted: Thu Mar 14, 2019 9:50 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1271
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
View user's profile Send private message Visit poster's website
smeunier
PostPosted: Fri Mar 15, 2019 6:21 am Post subject: Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 301

Thank you Morag, this will be helpful in our march forward.
Back to top
View user's profile Send private message
smeunier
PostPosted: Wed Aug 07, 2019 7:43 am Post subject: Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 301

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
View user's profile Send private message
smeunier
PostPosted: Wed Aug 07, 2019 7:55 am Post subject: Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 301

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
View user's profile Send private message
gbaddeley
PostPosted: Wed Aug 07, 2019 3:22 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2026
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
View user's profile Send private message
hughson
PostPosted: Wed Aug 07, 2019 3:54 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1271
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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Fri Aug 09, 2019 4:45 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20119
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
View user's profile Send private message Send e-mail
hughson
PostPosted: Sun Aug 11, 2019 2:34 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1271
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
View user's profile Send private message Visit poster's website
smeunier
PostPosted: Mon Aug 12, 2019 10:44 am Post subject: Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 301

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
View user's profile Send private message
hughson
PostPosted: Mon Aug 12, 2019 2:39 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1271
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
View user's profile Send private message Visit poster's website
smeunier
PostPosted: Tue Aug 13, 2019 11:14 am Post subject: Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 301

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
View user's profile Send private message
fjb_saper
PostPosted: Tue Aug 13, 2019 11:01 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20119
Location: LI,NY

Hmm.... Did you even look at clustered topic hosts???
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
hughson
PostPosted: Wed Aug 14, 2019 12:04 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1271
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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Wed Aug 14, 2019 4:25 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20119
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
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexGeneral IBM MQ SupportMQ Internal Broker V6 to V9 coeexistence
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.