Hi Claus, hi Serdar,

the pull request is up: https://github.com/apache/camel/pull/29421
(CAMEL-26735).

It follows the points from this thread. The reconnect logic is in a class of
its own, TLS goes through sslContextParameters and VertxHelper, and the
integration tests use the Mosquitto and HiveMQ services of test-infra,
including reconnect after a broker failure and restart. The description
explains how cleanStart=false and in-flight QoS 1/2 messages behave when the
connection drops.

Serdar, looking forward to your review and the run against your broker.

Best regards,
Andreas


Von: Andreas Huber <[email protected]>
Datum: Freitag, 6. November 2026 um 18:34
An: Serdar Gökay <[email protected]>; [email protected] 
<[email protected]>
Cc: [email protected] <[email protected]>
Betreff: AW: [DISCUSS] New component camel-vertx-mqtt: MQTT 3.1.1/5 client on 
the Vert.x MQTT client

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

Reply via email to