| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ Internal Broker V6 to V9 coeexistence |
« View previous topic :: View next topic » |
| Author |
Message
|
| hughson |
 Posted: Wed Aug 14, 2019 2:02 pm Post subject: |
 |
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| 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? |
I'm very confused by your response. Are you providing a solution to the problem of accessing the QUEUE called SYSTEM.BROKER.CONTROL.QUEUE or are you providing a means by which to convert the OP to V7 API Pub/Sub instead of pre-V7 Queued Pub/Sub interface?
_________________
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 2:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
AFAIK the OP is in the process of moving from pre V7 Pub/Sub to post V7 Pub/Sub (V9). Looking at what he had set up, a simple port of his topology is probably not adequate and would do him a disservice.
Looking into things like topic hosts (V8?) and other new features in the pub/sub set up should get him to a healthy pub/sub setup in V9.
Whether he is going to use his V6 pub/sub client to access that new set up or recompile with the V9 libraries is up to him and how fast he needs to get off the old setup. Be reminded that as V6 and V7 are already out of support and as such backwards functionality is no longer guaranteed!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Aug 14, 2019 2:38 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
AFAIK the OP is in the process of moving from pre V7 Pub/Sub to post V7 Pub/Sub (V9). Looking at what he had set up, a simple port of his topology is probably not adequate and would do him a disservice.
Looking into things like topic hosts (V8?) and other new features in the pub/sub set up should get him to a healthy pub/sub setup in V9.
Whether he is going to use his V6 pub/sub client to access that new set up or recompile with the V9 libraries is up to him and how fast he needs to get off the old setup. Be reminded that as V6 and V7 are already out of support and as such backwards functionality is no longer guaranteed! |
I thought he was just trying to figure out why his Queued Pub/Sub broker set up wasn't working on V9, and it turned out to be because he had clustered the SYSTEM.BROKER.CONTROL.QUEUE.
It is quite acceptable to use the Queued interface at V9. That's why it is there. Just because MQ V6 is out of support, does not mean that the Queued Pub/Sub interface (shipped in V9) is also out of the support - clearly it is supported since it is supplied in the V9 product.
I'm sure your suggestions will come in useful when he moves from that interface to the new interface but remember no recompilation is needed since it is JMS, all that is needed is to change the ProviderVersion.
Cheers,
Morag
_________________
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 7:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hughson wrote: |
I'm sure your suggestions will come in useful when he moves from that interface to the new interface but remember no recompilation is needed since it is JMS, all that is needed is to change the ProviderVersion.
Cheers,
Morag |
Not quite. Truly going to V9 will also require changing the JVM version, (java V8 ), changing the Jars being pointed to (com.ibm.mq.allclients.jar) and so on.
You are right though that the client code being JMS will not have to be recompiled...
As an aside, for non JMS, no need to use the SYSTEM.BROKER.DEFAULT.STREAM for publishing any more. You can just put your message to a topic alias and treat that topic alias as a queue... Of course you would have to create the topic object in the new topology....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Aug 20, 2019 8:20 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Quote: |
| the OP was trying to achieve by clustering the SYSTEM.BROKER.CONTROL.QUEUE? |
The intention of the single broker was for simplicity. The gateways were to offload client connectivity and distribute them between 3 MQ servers. The brokers SYSTEM.BROKER CONTROL and STREAM queues were cluster to share the broker.
In moving to V9.1, we were looking for minimal impact, just to get off of V6. In doing so, we wanted to leave the architecture as is. V9.1 did not support the SYSTEM.BROKER.* queues in a cluster. With that, we defined these queues as remote, and that worked fine.
However, what we have discovered with the 30+ applications, is that applications using V6 libraries, are fine with the single broker/remote queue setup. 2 clients which use V7.0.1 and V7.5 libraries, do not operate. Those applications require direct connectivity to a QMGR with a Broker running. This was not an expected outcome(in my mind), but I may be missing a concept. I need to maintain compatibility with V6 clients and V7+ clients with minimal disruption. Right now the brokers PSMODE is set to ENABLED. As long as the clients point to the Broker, all is fine. If the V7+ clients point to a QMGR with the PSMODE disabled, it fails with MQRC 2531. When PSMODE set to ENABLED on the Gateway Broker, the V7.5 clients are happy. Everyone plays nicely.
The net is I guess, that with distributed PUB/SUB clients across multiple QMGRS, the brokers must be enabled and in a hierarchy(simplest solution to handle all MQ clients levels). Looking for affirmation on that statement. |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Aug 20, 2019 9:00 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| smeunier wrote: |
| ... Those applications require direct connectivity to a QMGR with a Broker running. ... As long as the clients point to the Broker, all is fine. If the V7+ clients point to a QMGR with the PSMODE disabled, it fails with MQRC 2531. When PSMODE set to ENABLED on the Gateway Broker, the V7.5 clients are happy. |
Am unsure about the context you are referring to in the above snippets of your more recent post. You mention "broker" several times here. What are you referring to as a "broker"?
PSMODE(ENABLED) enables the internal Pub/Sub engine inside the queue manager AND ensures that the queued Pub/Sub interface, the SYSTEM.BROKER.CONTROL.QUEUE and stream queues are monitored - there is no requirement for a "broker" - but perhaps this is what you mean by a "broker"? The "Queued Pub/Sub Daemon" could be considered a "broker" I suppose?
Is PSMODE(DISABLED) is set no pub/sub of any form is possible - new or old interfaces, so it rather goes without saying that pub/sub applications would fail.
Hopefully I will understand your context a little better once I know what you mean by "broker" in this context - just one of those words with too many meanings!
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 20, 2019 11:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smeunier wrote: |
In moving to V9.1, we were looking for minimal impact, just to get off of V6. In doing so, we wanted to leave the architecture as is. V9.1 did not support the SYSTEM.BROKER.* queues in a cluster. With that, we defined these queues as remote, and that worked fine.
However, what we have discovered with the 30+ applications, is that applications using V6 libraries, are fine with the single broker/remote queue setup. 2 clients which use V7.0.1 and V7.5 libraries, do not operate. Those applications require direct connectivity to a QMGR with a Broker running. This was not an expected outcome(in my mind), but I may be missing a concept. I need to maintain compatibility with V6 clients and V7+ clients with minimal disruption. Right now the brokers PSMODE is set to ENABLED. As long as the clients point to the Broker, all is fine. If the V7+ clients point to a QMGR with the PSMODE disabled, it fails with MQRC 2531. When PSMODE set to ENABLED on the Gateway Broker, the V7.5 clients are happy. Everyone plays nicely.
|
I think you'll find that there is no need for the queue manager you're connecting to to have publications enabled. However you will need default routing between the queue manager you're connecting to and the "broker" queue manager that has pub/sub enabled. In JMS you can specify the "broker" qmgr name and it need not be left blank (same as the qmgr you're connected to). This should then use a default route to the "broker" and a "default" route back. Hope you executed the runmqsc script for pub/sub defining the queues on both the broker and local qmgrs.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smeunier |
| Posted: Wed Aug 21, 2019 5:09 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Quote: |
| Am unsure about the context you are referring to in the above snippets of your more recent post. You mention "broker" several times here. What are you referring to as a "broker"? |
Sorry Morag, I was overloading the term "broker"
| Quote: |
| As long as the clients point to the Broker, all is fine |
This really should have said. As long as the client(V7+) points to a Queue Manager where psmode(ENABLED), will it work. I think in this context, V7+ clients use the internal broker. If by default the Broker QMGR is not specified it tries to use the local QMGRS. Which we had disabled. It was disabled, to force all interaction with the Queue Manager that has PSMODE(ENABLED), without setting up a Broker network. V6 clients work just fine, as we have the SYSTEM.BROKER.CONTROL.QUEUE and SYSTEM.BROKER.DEFAULT.STREAM queue defined as QR to the QMGR with PSMODE(ENABLED). So what I'm guessing here, is that the clients connecting to the QMGR which does not have PSMODE(ENABLED) need to change their applications subscriptionStore value to the PSMODE(ENABLED) queue manager or connect directly to that QMGR itself. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
