No error thrown if message is sent to a non-existent topic

Question

When using IBM.XMS to send messages to a topic that does not exist no exception is thrown. When trying the same with a queue, I am kindly notified that the queue manager or queue don't exist.

This is how I create a connection and send messages to a topic:

XMSFactoryFactory xmsFactoryFactory = XMSFactoryFactory.GetInstance(XMSC.CT_WMQ);
IConnectionFactory ibmConnectionFactory = xmsFactoryFactory.CreateConnectionFactory();
ibmConnectionFactory.SetStringProperty(XMSC.WMQ_HOST_NAME, "frimasrv");
ibmConnectionFactory.SetIntProperty(XMSC.WMQ_PORT, 1415);
ibmConnectionFactory.SetStringProperty(XMSC.WMQ_CHANNEL, "CH1");
ibmConnectionFactory.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, XMSC.WMQ_CM_CLIENT);
ibmConnectionFactory.SetStringProperty(XMSC.WMQ_QUEUE_MANAGER, "API");

IConnection connection = ibmConnectionFactory.CreateConnection();
connection.ClientID = "client id";
ISession session = connection.CreateSession(false, AcknowledgeMode.AutoAcknowledge);

IDestination destination = session.CreateTopic("this.does.not.exist");
IMessageProducer producer = session.CreateProducer(destination);
IMessageConsumer durableConsumer = session.CreateDurableSubscriber(destination, "subscriptionName");

IMessage myMessage = session.CreateTextMessage("text");
producer.Send(myMessage);

Supplement the call of session.CreateTopic(...) with session.CreateQueue(...) and session.CreateProducer(...) will fail. This is the behaviour I also expect when using topics.

My questions are:

How come that no problems arise when sending to a topic that does not exist? Is part of my configuration wrong? Is there some other way to verify if a topic actually exists?

Answer 1

How come that no problems arise when sending to a topic that does not exist?

Because the moment you send a message to a topic or subscribe to a topic it exists. The queue manager will auto-vivify it for you.

According to the JMS 2.1 specification:

Some products require that topics be statically defined with associated authorization control lists, and so on; others don’t even have the concept of topic administration.

IBM MQ is one of the products that does not require topics to be statically defined.

You may have misunderstood IBM MQ's use of topic objects. These do not define the topics themselves, but rather they provide a pointer to the place in the topic hierarchy where an access control list applies. For example, consider the following topic hierarchy:

Produce
   Fruits
      Apple
      Banana
      Cranberry
   Vegetables
      Asparagus
      Beet
      Celery

If you define a topic Fruits and point it at the topic string Produce/Fruits you can then authorize people to publish or subscribe to the portion of the topic tree from Produce/Fruits on down. Those with the authorization will not be able to access Produce/Vegetables unless you provide them access through a topic object pointing there.

As a rule, it is best to define topic objects all at a certain level of the topic tree. As you can see above, defining a topic object at Produce grants access to the entire topic tree, but you need only one topic object. Define the objects at the second level and you need two to cover the tree (one at Fruits and one at Vegetables) but have more granularity in the security model. Define the topics at the third level and you have extreme granularity, but also have many more topic objects to administer.

IBM MQ defines a default topic object SYSTEM.BASE.TOPIC which points to the root of the global topic space. Anyone with access to SYSTEM.BASE.TOPIC can access any topic. By default, this includes only MQ administrators.

If you define a topic called Fruits and point it at the topic string Produce/Fruits then you have two choices when you want to open that topic. If you open the topic object which results in IBM MQ substituting the topic string to which the object points. You can also open the topic string directly. Either of these results in the same effective authorization since IBM MQ always authorizes based on the final topic string.

If you specify both a topic object and a topic string, the topic string in the defined object is used as the prefix to the string that you provide. The two are concatenated to produce the full topic string. For example, if you specify both the topic object Fruits (which points to the string Produce/Fruits in the example above) and the string Produce/Fruits, MQ concatenates these and vivifies a topic called Produce/Fruits/Produce/Fruits. Try not to do that. IF you do need to do that, make sure you understand the mechanics as described in the Combining topic strings page.

If you check the IBM MQ Pub/Sub API or the IBM implementation of the topic connection factory, you will see that these contain two fields, one for the topic object and one for the topic string.

When you specify a topic object in your connection factory, that object must exist. Specify a topic string and MQ will auto-vivify it for you if you are authorized to that string.

I am guessing the ID you are using has admin rights or has been granted access to SYSTEM.BASE.TOPIC since you are able to publish at all. You will therefore not receive any errors for any topic string to which you publish.

Please see also the Topic Strings page in the manual for a general background of how IBM MQ manages topics.

Answer 2

Have you ran the "IBM Message Service Client for .NET" installer?

XMS : XmsFactoryFactory moans about missing IBM.XMS.Impl

Here is another helpful post on SO:

How do I get Websphere MQ connection status and how do I reset the connection: