2
votes

When i use this code as subscriber:

MQTopic QMsSubscription = qm.accessTopic("qmstop", "", CMQC.MQTOPIC_OPEN_AS_SUBSCRIPTION, CMQC.MQSO_CREATE);

MQMessage recvQMsMsg = new MQMessage();
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.options = MQConstants.MQGMO_WAIT;
gmo.waitInterval = MQConstants.MQWI_UNLIMITED;

QMsSubscription.get(recvQMsMsg, gmo);

and this code for publisher:

MQTopic QMsPublisher = qm.accessTopic("qmstop", "", CMQC.MQTOPIC_OPEN_AS_PUBLICATION, CMQC.MQOO_OUTPUT);
MQMessage sendQMsMsg = new MQMessage();
sendQMsMsg.writeString(thisQM);
QMsPublisher.put(sendQMsMsg);

these code work well in one machine with one Queue manager but when i use these code in a cluster with many Queue managers the message not sent to other machines.

how to create a topic-string on the fly in a cluster?

1
You need to tell WMQ that the topic should be of type cluster. That is not "on the fly" though. www-01.ibm.com/support/docview.wss?uid=swg27016146#3Petter Nordlander

1 Answers

0
votes

Normally, you would not use a topic like qmstop in MQ. The reason for this is that MQ uses Pub/Sub for many of its own operations and anyone who can publish or subscribe at the top of the topic tree would be able to inject or subscribe to MQ internal pub/sub messages.

The way it is intended to work in MQ is that you first design a topic namespace. Typically this has a root node below which the rest of the topic tree can be broad and shallow, tall and deep, or sparse. However, there's always the one root node at least.

Once you have the root node, you define a topic object for it. For example, imagine the following topic namespace:

Items
   Produce
      Fruits
         Apples
         Bananas
         Cherries
      Vegetables
         Asparagus
         Beets
         Carrots

If you define a topic object that points to Items, you can advertise it to the cluster. Once the topic object is defined, you can hang access control lists off of it so that you can define who can publish and who can subscribe.

Someone with access to publish or subscribe to Items can then dynamically create any topic string with Items as the root. They could, for example, publish or subscribe to Items/Produce. Since Items has been advertised to the cluster, the dynamically created Items/Produce would be distributed through the cluster.

Similarly, if topic objects were defined which pointed to Items/Produce/Fruit and Items/Produce/Vegetables and advertised to the cluster, you could authorize people to these. In that case, someone authorized just to Items/Produce/Fruit could not publush or subscribe to Items/Produce/Vegetables. However, if they wanted to publish to Items/Produce/Fruit/Apples/Gala they would be able to dynamically create that topic and it would distribute through the cluster.

What you do not want is to have QMgrs publish all their topics across the cluster because they would then get each others' internal traffic on system topics. Aside from sucking up resources on the QMgr, the network might get saturated from the ginormous netstorm that would result in even a small cluster.

So the short answer is that if you were to define the top of your topic namespace and advertise it to the cluster, you can then dynamically generate topics below that root node which also propagate around the cluster.