Wierd connect / disconnects on MQTT adapter

[sansmoraxz]

Hi,

We are trying to adapt the stack into k8s.

We have observed some wierd behaviour with the emqx cluster created via emqx operator.

Logs spam periodically every 500 ms or such:

[pod/mqtt-adapter-7547bdf7f5-8hx5s/mqtt-adapter] {"time":"2026-02-09T06:00:51.557458256Z","level":"INFO","msg":"Accepted new client"}
[pod/mqtt-adapter-7547bdf7f5-8hx5s/mqtt-adapter] {"time":"2026-02-09T06:00:51.56434341Z","level":"INFO","msg":"disconnected client_id  and username "}
[pod/mqtt-adapter-7547bdf7f5-8hx5s/mqtt-adapter] {"time":"2026-02-09T06:00:51.567030101Z","level":"WARN","msg":"EOF"}

The adapter is functioning properly but not sure where and why this is coming from. Even disabling external traffic doesn't seem to fix the issue. If we enable journal it's being captured there too. Just some odd behaviour.

[arvindh123]

Hi @sansmoraxz,
Just to clarify — are you using EMQX as the backend broker instead of RabbitMQ or VerneMQ in your setup?

[sansmoraxz]

Yes

[sansmoraxz]

Via this crd: https://github.com/emqx/emqx-operator

Pretty basic setup, and connected that broker (1 replica now) to our mqtt adapter deployment via service route.

[dborovcanin]

@sansmoraxz Which version or SuperMQ are you using?

[sansmoraxz]

v0.18.5

[sansmoraxz]

I think I figured out what's happening. Wasn't due to broker, it was health checks (TCP on 1883) that was triggering it and the adapter was parsing it as some MQTT traffic (even though no CONNECT was sent, I think).

And I do have a question here, what's the recomended approach to deploy (following kubernetes best practices), as the health checks via TCP sockets mess up journals and traces, and there's no http socket exposed like coap's SMQ_COAP_ADAPTER_HTTP_PORT

[dborovcanin]

Just to double check - this is mostly log pollution, you are not facing any MQTT-related problems? Does EMQX expose health check on the same port as the MQTT traffic? As for the k8s best practices, @arvindh123 or @JeffMboya can provide the answer.

[sansmoraxz]

Yes, mostly log pollution. We haven't deployed this yet, max we tested is with just 50 clients connected but not facing any other mqtt related issues for now.

And EMQX has it's proper health checks configured via it's operator which does via HTTP (/status on dashboard), it's working properly. No TCP based health checks on it.

[sansmoraxz]

Also I think the adaptor should ideally track the CONNECT and DISCONNECT packets, not the raw TCP connections (or if TCP needed controlled via some feature env var).

[felixgateru]

Hello @sansmoraxz, thank you again for raising the issue! To confirm your findings, the MQTT adapter uses mgate as a library to offer additional features, a big one being the ability to have custom handlers for packet types as expressed in the mgate README. To do this, we use an acceptor loop that accepts any TCP traffic. An HTTP call on the MQTT port is likely causing the logs.