hivemq-mqtt-client
hivemq-mqtt-client copied to clipboard
Java API unexpected disconnect: malformed topic
Hello there!
Using the Hive Java API (both v3 and v5) to connect to brokers where I don't control the topic space, occasionally I receive messages that are published to topics that the API considers bad: e.g. topics with wildcards +
and #
. The API abruptly disconnects without any obvious warning message. I had to use Eclipse IDE thrown exception breakpoints to try to find out what was happening internally, and then also eventually figured out that I could put a disconnect listener in to see the error message:
com.hivemq.client.mqtt.mqtt5.exceptions.Mqtt5DisconnectException: Exception while decoding PUBLISH: malformed topic
No indication of what the topic was. Through some trial-and-error I figured out it was wildcard chars. Strange, your JavaScript ~~API~~ Client (https://www.hivemq.com/demos/websocket-client/) is much more capable at dealing with unexpected characters, it happily receives PUBLISH
messages with +
and #
chars in the topic, no sweat.
Hopefully you can relax parsing rules to make the Java API more tolerant. Even though it's written in the MQTT spec [MQTT-3.3.2-2] that wildcard chars shouldn't be there, sometimes we run into this "in the wild" and ideally your API should be able to cope and stay online. And also/either log what the invalid topic was, and/or stay online and ignore it instead of just dying.
Thanks very much!
Hi @aaron-613 As you already said, this is a requirement of the MQTT specification:
The Topic Name in the PUBLISH Packet MUST NOT contain wildcard characters [MQTT-3.3.2-2].
MQTT is a standard which allows different devices/things/machines to communicate with each other. This only works if all implementations obey to the rules of the specification. As this rule is a "MUST" requirement, no implementation must violate it, otherwise it is not conform to the MQTT specification. This means, you should raise a bug at the broker you are using, as an MQTT broker must never accept malformed topics from publishers and also not send malformed topics to subscribers then.
Hi @SgtSilvio... thanks for the response. While I agree with the spec, I also think it's not the API's responsibility to enforce it... it should be left to the broker. There are multi-protocol message brokers (e.g. Solace) that support MQTT as one of many protocols, where having #
and +
in the topic string is perfectly valid.
This is the first API that I've seen that strongly enforces this requirement. As I said, even the Hive JavaScript ~~API~~ Client https://www.hivemq.com/demos/websocket-client/ is tolerant. As are all other MQTT APIs that I've used.
Thanks!
Both of you make a good argument. At a minimum, the client could be strict by default with an option to disable topic name validation.
I'll mark this as a feature request to be considered in a future release. Thanks for filing @aaron-613!