Another in the series of bitesize blog posts about features in MQ V8. Check out the whole series here.
Publish/subscribe in MQ can be very dynamic. The topic strings that subscribers and publishers are using will dynamically pop into existence as and when they're first used and the unused ones will get removed over time. Subscriptions can also easily be created and deleted by connected applications.
When you're monitoring an MQ system it's a very good idea to be aware of at least how many of these you have. For one reason, each topic string and subscription requires some level of resource and if you have a runaway application generating these you'll want to detect that sooner rather than later. It's possible to keep track of each of these through displaying lists of topic nodes (which are effectively each part of a structured topic string, and shouldn't be confused with the administratively configured topic objects) and lists of subscriptions on a queue manager and counting them up. But when you're monitoring a big system that's not so easy or convenient to do, especially if all you're trying to see is if the system is in a steady state or mysteriously growing over time.
For that reason we've added a couple of extra values in MQ V8 when displaying the queue manager wide publish/subscribe status. We now list the topic node count and the subscription count. So you can use this to periodically check the system is as you expect, or further investigation needs to be done.
How do you use it?
This information can be seen using the following command:
DISPLAY PUBSUB ALL
And you'll get back the following:
These are also visible when using MQ Explorer, on the publish/subscribe status page for the queue manager.
And if they are growing?
To investigate further, and see what's being generated, you can use the following commands (these are not new to MQ V8):
DISPLAY TPSTATUS('#') - this will return every topic node
DISPLAY SUB(*) - this will return every subscription
(Obviously, if you don't spot the growth until you have many thousands and thousands of entries, simply displaying every entry may not be the best approach.)
This is probably the subject for future blog posts in their own right, but why might these be growing?...
One reason for subscription growth can be due to the use of non-durable subscriptions and connections being leaked (you'd see this in the number of connections on the system), meaning the subscriptions don't get removed.
Continued topic node growth may be down to the design of the topic tree (which contains all the topic nodes that represent the topic strings being used by the publishers and subscribers). If the topic strings have very specific information encoded into them (for example an order reference number), you may find each publication is effectively on a new topic string, which will need new topic nodes in the topic tree, and rarely reused. If you publish fast enough the creation of topic nodes will out pace the queue manager's garbage collection, which will remove them when it detects that they're no-longer in use. One option is to make the garbage collection more aggressive (check out the TREELIFE attribute of a queue manager), but if the creation rate is too high you'll start to spend all your time creating and removing topic nodes, increasing the background load on the queue manager. At this point you need to decide if the topic tree design can be improved to reduce that overhead.
As an aside, we've also made improvements to the performance of this topic node creation/removal area in MQ V8!