huber-and opened a new pull request, #29421:
URL: https://github.com/apache/camel/pull/29421
# Description
A new component `vertx-mqtt` (`vertx-mqtt:topic`) that connects to an MQTT
broker with the Vert.x MQTT client
(`io.vertx:vertx-mqtt`), as discussed on dev@camel ("[DISCUSS] New component
camel-vertx-mqtt").
Jira: https://issues.apache.org/jira/browse/CAMEL-26735
## Features
- Consumer and producer, MQTT 3.1.1 and MQTT 5
- QoS 0, 1 and 2, retained messages, will message, clean start and session
expiry
- MQTT 5 properties as headers: content type, response topic, correlation
data, message expiry interval, user properties
- Manual acknowledgements (`manualAcksEnabled`) and `receiveMaximum` for the
consumer
- Back pressure: exchanges are processed off the event loop, the client
stops reading when `maxPendingMessages` wait
- TLS through `sslContextParameters` (`VertxHelper` of camel-vertx-common),
host name verification on
- Username and password (`security = "secret"`)
- Consumer health check (readiness)
## Reconnect
The Vert.x MQTT client does not reconnect by itself yet
(vert-x3/vertx-mqtt#197). With `automaticReconnect` (default)
the component reconnects with a delay that starts at `reconnectDelay` and
doubles up to `maxReconnectDelay`, and
subscribes again after every connect. All of this lives in
`VertxMqttReconnector`, so it can be dropped once the client
reconnects on its own. I'm happy to help with #197 on the Vert.x side.
A consumer starts even when the broker cannot be reached and keeps trying;
the health check and the exception handler
report why nothing arrives. A producer fails its exchange while not
connected.
## What happens when the connection drops
**Producer, QoS 1 and 2.** An exchange completes when the broker
acknowledged the message (PUBACK for QoS 1, PUBCOMP
for QoS 2). The Vert.x client keeps no session of its own, so a message that
was sent but not yet acknowledged when
the connection is lost is **not** sent again by the client: its exchange
fails with "The connection to the MQTT broker
... was lost before the message was acknowledged". Redelivery is left to
Camel's error handling (redelivery policy,
dead letter channel), which keeps the outcome visible per exchange instead
of a silent retry. A message without an
acknowledgement within `ackTimeout` fails as well.
**Consumer, `cleanStart=false`.** The broker keeps the session of the client
(with MQTT 5 for
`sessionExpiryInterval` seconds) and holds QoS 1 and 2 messages while the
consumer is disconnected. After the
reconnect with the same `clientId` the broker delivers them, and the
component subscribes again. A consumer that stops
keeps its subscription at the broker. With `cleanStart=true` (the default)
every connect starts a fresh session and a
stopping consumer unsubscribes.
**Consumer, in-flight QoS 1 and 2.** By default a message is acknowledged as
soon as it arrives. With
`manualAcksEnabled` it is acknowledged only once its exchange completed
successfully; a message whose exchange failed,
or that was in flight when the connection dropped, stays unacknowledged, and
the broker delivers it again after the
next connect if the session survived (`cleanStart=false`, within
`sessionExpiryInterval`). This is at-least-once:
a route must tolerate duplicates.
## Tests
- 67 unit tests
- 25 integration tests through camel-test-infra (`mirror.gcr.io` images):
- `MosquittoIT`, `HiveMqIT`: the same 11 scenarios against Mosquitto 2.0
and HiveMQ CE
- `VertxMqttReconnectAfterFailureIT`: consumer starting without a broker,
producer failing and recovering, both
recovering after a broker restart
`mvn clean install -Psourcecheck` passes in the module.
## Changes outside the module
- Regenerated catalog, component and endpoint DSL, docs symlinks and nav,
`camel-bom`, the lists in `ArtifactUtils`,
camel-main and camel-kamelet-main, and an entry in `coverage/pom.xml`.
- `MojoHelper.getComponentPath()` lists the sub-modules of `camel-vertx`
explicitly; without the new entry the catalog
and DSL generators skip the component.
## AI assistance
The component was written with the help of Claude Code (Anthropic); the
commits carry `Co-Authored-By` trailers. I
reviewed and tested all of it and take responsibility for the contribution.
# Target
- [x] I checked that the commit is targeting the correct branch (Camel 4
uses the `main` branch)
# Tracking
- [x] If this is a large change, bug fix, or code improvement, I checked
there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for
the change (usually before you start working on it).
# Apache Camel coding standards and style
- [x] I checked that each commit in the pull request has a meaningful
subject line and body.
- [x] I have run `mvn clean install -DskipTests` locally from root folder
and I have committed all auto-generated changes.
# AI-assisted contributions
- [x] If this PR includes AI-generated code, commits have proper
co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR
description identifies the AI tool used.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
