Hi all,
At first I thought we were bundling an MQTT client with a MQTT broker.
But it turns out that when enabling the MQTT subsystem we actually start a
broker and attach our stuff internally.
This completely binds us to the Moquette MQTT broker and it’s impossible to use
IoTDB in an existing MQTT system.
I would propose to refactor this part to make use of an MQTT client with the
option to start a Moquette MQTT server, if no other MQTT broker is available.
What do you folks think?
Chris
Von: Christofer Dutz <christofer.d...@c-ware.de>
Datum: Freitag, 1. September 2023 um 14:46
An: dev@iotdb.apache.org <dev@iotdb.apache.org>
Betreff: [DISCUSS] Configuration of the MQTT subsystem
Hi folks,
I’m currently working hard on implementing a SparkplugB PayloadFormatter that
would allow us to directly consume a SparkplugB mqtt stream.
However have I noticed two things:
1. The current PayloadFormatter interface, doesn’t pass the topic to the
format method (in Sparkplug the device Id is located in that)
2. The current config option enable_mqtt_service does two things
* It starts a local MQTT broker
* It registers as client to the MQTT broker configured in the settings
I worked around the Problem in 1) by Adding a PayloadFormatterV2 interface
which extends the PayloadFormatter, that adds one method:
List<Message> format(String topic, ByteBuf payload);
Then I extended the MPPPublishHandler to check if the handler instance
implements V2 or not.
If it’s a V2 it calls the new method and passes the topic along, if not, it
uses the old one. This way no compatability problems should occur.
However I would never use a broker like the moquette broker in a large scale
production environment. Here I’d probably go for HiveMQ or alike.
Unfortunetely we currently can’t enable the MQTT consumer stuff without
starting the broker.
I think we need 2 settings here.
Chris
