Hi Andreas, Thanks for reaching out, and for offering the code.
Yes, we're interested. A Vert.x-based MQTT component is a good fit for Camel. It's close to Quarkus and Vert.x, and suits users who want a fast, non-blocking client. Since Vert.x 5.2 the client also speaks MQTT 5, so it can sit next to camel-hivemq and camel-paho-mqtt5. The one thing I'd like to agree on up front is reconnection. The Vert.x MQTT client doesn't reconnect by itself yet (vert-x3/vertx-mqtt#197). Robust reconnect and resubscribe belong in Vert.x, not in Camel. So we can take your reconnect code for now. Please keep it separate in the component so it's easy to remove. Once Vert.x ships reliable reconnection, we'll switch to it and drop the Camel code. It would help a lot if you could also bring your experience to the Vert.x project and help get #197 done there. In the PR, please describe how your code handles cleanSession=false and QoS 1/2 messages that are still in flight when the connection drops. I'm also looping in Serdar, who works on Camel's industrial connectors (milo, plc4x, mtconnect, paho-mqtt5, hivemq) and tests MQTT on factory floors with real hardware. Serdar, it would be great to have your eyes on this, especially on reconnection and QoS 1/2 behaviour when the network drops. Andreas, it would help if the reconnect tests cover the same scenarios as camel-hivemq, so we can compare the two components. Some practical notes: - A CAMEL JIRA plus a PR against main is the way to go. - For TLS, please use Camel's sslContextParameters. VertxHelper in camel-vertx-common already converts it to Vert.x options. - For the tests, please use the Mosquitto/HiveMQ services in test-infra, with container images that are not from Docker Hub. - For the AI-assisted parts, please add Co-authored-by trailers to the commits as described in our contributing guide. Thanks, Claus On Fri, Nov 6, 2026 at 3:53 PM Andreas Huber <[email protected]> wrote: > Hi all, > > at IoT Invent GmbH we have built a Camel component for MQTT 3.1.1 and 5 on > the Vert.x MQTT client (io.vertx:vertx-mqtt), and we would like to > contribute it as a new module next to camel-vertx-http and > camel-vertx-websocket. Since Camel main runs on Vert.x 5, Vert.x users get > MQTT without a second network stack, with both MQTT versions behind one API. > > It supports consumer and producer, QoS 0/1/2 with manual acknowledgement, > MQTT 5 properties, reconnect with resubscribe, back pressure, TLS and a > consumer health check. It is about 2,000 lines plus tests against Mosquitto > and HiveMQ, already structured like a module of components/camel-vertx with > generated metadata and docs, under the Apache License 2.0. Its only new > dependency is io.vertx:vertx-mqtt 5.2.x. > > Two questions: > > Is there interest in this component? > Would a pull request against main with a CAMEL JIRA issue do, or should it > go through IP clearance with a software grant? We are prepared to sign what > is needed. > > Parts of the code were written with an AI coding assistant (Anthropic > Claude), which we would attribute as your contributing guide describes. We > are happy to share the code. > > Thanks, > Andreas Huber > IoT Invent GmbH > > > -- Claus Ibsen
