Hi Chris, That will be so nice to do so, we can use different maven cmd to get different packages for different requirements!
On Wed, Jan 28, 2026 at 4:42 PM Christofer Dutz <[email protected]> wrote: > Hi all, > > I’m not saying it HAS to be separate … It’s written in Java … so you COULD > integrate it the same way you do moquette. Just for services like this, I > personally would prefer to have them run in separate JVM instances (Also > from a security perspective). > > Chris > > Von: Yuan Tian <[email protected]> > Datum: Mittwoch, 28. Januar 2026 um 09:30 > An: [email protected] <[email protected]> > Betreff: Re: [D] BifroMQ and MQTT ingestion for IoTDB > > Actually, for such users, since they have low write loads, they prefer > 1C1D. Forcing them to set up a separate MQTT broker, write custom consumer > code, and then manually pipe the data into IoTDB would be a *total > disaster*. They > want to minimize the number of components in their stack to reduce > operational overhead. > > On Wed, Jan 28, 2026 at 4:26 PM Yuan Tian <[email protected]> wrote: > > > Hi Chris, > > > > Totally agree with that. While IoTDB needs a scalable, distributed MQTT > > solution, we should also retain *Moquette* as a lightweight broker. Many > > users have relatively low write loads and prefer an *out-of-the-box* way > > to persist MQTT messages without writing any code. The current Moquette > > implementation fits their needs perfectly. > > > > > > Best regards, > > ---------------------- > > Yuan Tian > > > > > > On Wed, Jan 28, 2026 at 4:09 PM Christofer Dutz < > [email protected]> > > wrote: > > > >> Hi all, > >> > >> The reason I brought this up was: > >> Right now we embed (ok now it’s separated) Moquette. > >> That’s a lightweight MQTT broker, but it can’t do clustered mode. So > >> currently if we start the MQTT broker on one of our data-nodes, that > >> becomes a single point of failure. Or we have one broker for each > data-node > >> and these don’t mesh. > >> > >> Using Apache BifroMQ could allow us to spin up an MQTT broker cluster > >> that grows with the IoTDB cluster. > >> > >> However, I would love to see it deployed alongside IoTDB and us use a > >> real MQTT client for ingesting messages, instead of our current > approach of > >> hacking this functionality into the broker. > >> > >> Chris > >> > >> > >> Von: Pengcheng Zheng <[email protected]> > >> Datum: Mittwoch, 28. Januar 2026 um 03:35 > >> An: [email protected] <[email protected]> > >> Betreff: [D] BifroMQ and MQTT ingestion for IoTDB > >> > >> Hi all, > >> > >> In a recent chat with Chris, he mentioned BifroMQ as an interesting MQTT > >> broker architecture - actually this topic has come up more than once > when > >> discussing future IoT ingestion patterns. > >> > >> From a quick study, BifroMQ explores some design ideas that differ from > >> more established brokers like EMQX or HiveMQ, such as shared > subscription > >> as a core primitive, native multi-tenancy, and cloud-native scaling [1]. > >> These seem potentially useful for large-scale or SaaS-style ingestion > >> pipelines. > >> > >> This is not to suggest replacing existing MQTT integrations, but I > wonder > >> whether this direction could be interesting for future IoTDB ingestion > >> architectures. > >> > >> Curious to hear your thoughts, and whether anyone has hands-on > experience > >> with BifroMQ. > >> > >> > >> [1] https://bifromq.apache.org/ > >> > >> > >> Best regards, > >> Pengcheng > >> > > >
