Hi Serdar, thanks, that's very welcome. A review focused on reconnection and QoS 1/2, plus a run against a real broker in your setup, is exactly what this component needs.
A bit of context from our side: at IoT Invent we have gathered more than 20 years of experience with IoT and Auto-ID, primarily in logistics. Our new platform uses Camel for its integration flows, and that is where camel-vertx-mqtt comes from. So it is good to see the same need on the shop floor. I'll let you know once the PR is up. Best regards, Andreas Von: Serdar Gökay <[email protected]> Datum: Freitag, 6. November 2026 um 18:13 An: Andreas Huber <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]> Betreff: Ynt: [DISCUSS] New component camel-vertx-mqtt: MQTT 3.1.1/5 client on the Vert.x MQTT client Hi Andreas, Thanks for looping me in, I’m glad to help. Some context: at Etzel we build MES and IIoT solutions on real shop-floor equipment. IT and OT keep converging, and what Camel has solved for years on the IT side (routing, error handling, transformation) is exactly what OT integration needs. So it is great to see more people building OT connectivity on Camel. Andreas, I'll review the PR once it is up, with a focus on reconnection and QoS 1/2 behaviour when the network drops, and I'll also run it against a broker in our test setup. Best regards, Serdar [Image]<http://www.etzel.com.tr/> Serdar Gökay MES Çözüm Mimarı | MES Solution Architect C :+90 531 360 66 47<tel:+905313606647> T :+90 216 325 51 11<tel:+902163255111> [email protected]<mailto:[email protected]> [Image]<https://www.linkedin.com/in/serdar-gokay> Atatürk Mahallesi, Erzincan Sokak No:28 Golive Plaza Ataşehir/İstanbul Kimden: Andreas Huber <[email protected]> Tarih: Cuma, 6 Kasım 2026 18:38 Kime: [email protected] <[email protected]> Bilgi: Serdar Gökay <[email protected]> Konu: AW: [DISCUSS] New component camel-vertx-mqtt: MQTT 3.1.1/5 client on the Vert.x MQTT client 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
