When I subscribe an MQTT client to a Universal Messaging broker with the multi-level wildcard topic filter “#”, then the broker does not behave as expected. I’ll only receive messages for topics that have already existed before. I won’t receive messages that will be published to new topics. I’ll only be able to listen to the new topics, if I subscribe again after these topics have been used for the first time. The expected behavior is that I’ll receive any message – no matter whether the topic has been used in the past or whether the topic is new.
This issue does not exist with the single-level wildcard “+”.
Reference: MQTT specification regarding “Topic Names and Topic Filters” MQTT Version 3.1.1
This is also my understanding. Can you provide some more information.
What version (and fix level) of Universal Messaging are you using, what is the client implementation and what is the version of the MQTT protocol? I’m assuming it’s 3.1.1 but I’d like to double check just in case.
thank you for your support. Universal Messaging tells me “buildInfo="10.5.0.1.124687"”. Yesterday I tested with MQTTBox, and there I had set the checkmark telling “Broker is MQTT v3.1.1 compliant”. Now I’ve made a few more tests. When I remove said checkmark, I get a connection error. Now I’ve also experimented with the Eclipse Mosquitto command line client. There I experience the same issue with the #-wildcard. This client is connecting seamlessly using either of MQTT 3.1.1 and MQTT 3.1, and the choice of version does not affect the issue.
Apologies for the delay.
I can create a ticket for you. I checked it out and I suspect it may be a cosmetic issue in the matcher which seems to work differently depending on whether the topics are created prior to the subscription or after it. Can you confirm if the topic you are testing with is nested in any folders or whether it was created directly in the root context? I ran a few quick tests and surprisingly topics nested in folders worked fine, whereas these in the root were not picked up by the dynamic subscription watchdog.
If this is confirmed we will try to have it fixed in the next official fix for the product.
If you’d like to follow the progress of your ticket you’ll need to create one in our customer portal - https://empower.softwareag.com/.
We will try to get that fixed in the next official product fix regardless of whether you file it through the Empower portal or not.
thank you for guiding me and for investigating this issue further.
Nested topics are in fact not affected. I’ve never tried that before. Messages arrive even if the root element of the nested topic is completely new. Only bare root topics have the problem.
I’ve got an empower account, but don’t know where to file the bug report. Hence I’d like to ask you to create the ticket.
I’ve created a ticket in Jira about it. I could provide a test patch, but I believe they need to be approved by the global support organization.
Let me know if you need one and we can work it out.
thank you! My broker can operate without the patch now. The bug only caused irritations when the broker came to live with empty memory. I fear I wouldn’t know how to properly deploy the patch anyway. Hence the easiest solution for both of us is aiming for the next release.