Hi Claus, hi Serdar, thanks a lot, that’s great to hear.
I’ll take care of the points you raised: Reconnect and resubscribe move into a class of their own, so that the component can switch to Vert.x once the client reconnects by itself. I’m already contributing to vertx-mqtt (WebSocket client, keep alive fixes) and will gladly help with #197 there. TLS will go through sslContextParameters and VertxHelper. The tests will use the Mosquitto and HiveMQ services of test-infra. I’ll look at the reconnect tests of camel-hivemq and cover the same scenarios, so that the two components can be compared. The PR will describe how cleanStart=false and in-flight QoS 1/2 messages behave when the connection drops, and the commits will carry Co-authored-by trailers. I’ll open a CAMEL JIRA issue and follow up with the PR. Best regards, Andreas Von: Claus Ibsen <[email protected]> Datum: Freitag, 6. November 2026 um 16:17 An: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Betreff: Re: [DISCUSS] New component camel-vertx-mqtt: MQTT 3.1.1/5 client on the Vert.x MQTT client 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
