Unstable WebSocket connection, recv aio error Object closed

[ElectricEra]

I'm trying to connect to MQTT Broker over WebSocket protocol.
The connection is not established consistently, it results in errors from time to time.

Expected behavior
A connection is established every time.

Actual Behavior
A connection is not established every time.

To Reproduce
Broker setup:
I've used Docker image of NanoMQ broker:
https://hub.docker.com/r/emqx/nanomq
and specified NANOMQ_WEBSOCKET_URL
(docker run -d -p 1883:1883 -p 8883:8883 -p 8083:8083 -e NANOMQ_WEBSOCKET_URL="nmq-ws://0.0.0.0:8083/mqtt" --name nanomq emqx/nanomq:latest)
Latest at the moment is [0.17.3]

Client setup:
For connection setup I've been trying default examples from here (tried both of them, modified mqtt-client-Node.js to connect over WS too). They've resulted in the same outcome.
https://github.com/emqx/MQTT-Client-Examples/tree/master/mqtt-client-React
https://github.com/emqx/MQTT-Client-Examples/tree/master/mqtt-client-Node.js

Connection works the first time, but after first time the client is connected, sometimes connection is not established.

• Client side:
  The error which is logged during reconnection on client side is undefined

client.on('reconnect', (error) => {
  console.log(`Reconnecting...`, error)
})

Reconnecting... undefined

• Broker side:
  The error on Docker Container is

WARN  /nanomq/nng/src/sp/transport/mqttws/nmq_websocket.c:126 wstran_pipe_recv_cb:  recv aio error Object closed

Environment Details

• Broker: emqx/nanomq:latest (at the moment [0.17.3]) Client: https://github.com/mqttjs/MQTT.js
• Mac OS 13.2.1

Additional context
This issue is irregular. Haven't figured the pattern besides it working the first time a client is trying to connect.
I'm able to "consistently reproduce" it by continuously trying to connect/disconnect to a broker after 1 minute of first connection.

[JaylinYu]

HI ElectricEra,

I have tested the example code and MQTTX (they all base on mqtt.js lib, so they should work in same way), and I fail to reproduce your case. Could you provide more logs regarding this scenario? including the context, the only log you paste here means the TCP connection is actively closed by the client.

[ElectricEra]

What I assume is happening - when the Client tries to connect, it establishes a connection to a Broker over WS. Then, if for whatever reason the connection is not disconnected gracefully - it "hangs" (resulting in that error), disabling any other connection from being established. (As described above, I was able to get to this state by trying to rapidly connect/disconnect)

From my client I can see that it sends a "reconnect" message over and over again but with no success. I have to restart a NanoMQ Broker to connect to it again.

I would hope that Broker would "free up" the port and would allow to connect to it again.

Do you think this is the case? If not - feel free to close the issue

[JaylinYu]

From my client I can see that it sends a "reconnect" message over and over again but with no success. I have to restart a NanoMQ Broker to connect to it again.

This definitely seems weird. Any other logs pops out from nanomq during this? If not this should be more like a network problem.

Or, perhaps the client is using the same socket which has been explicitly closed by broker, then you probably experience such a case that looks like it is a hang (but actually not), because broker doesn't even receive anything！

[JaylinYu]

Hi @ElectricEra I found a similar issue, it has likely the same symptom as your issue here.
The blocking happens when clients send malformed packets or exceed recv/send quota or any kinds of situation that broker think it is an error. Then broker disconnect this client but never really recover.

If you have time to try it out and give feedback would be appreciate

[ElectricEra]

Will try, thanks for the updates and fixes!

[yacinehmito]

I am on version 0.19.5 and seeing something similar.

[JaylinYu]

We believe our team has successfully resolved this issue #1210 and sincerely apologize for any inconvenience caused. Please verify the fix on the updated master branch, any comment would be appreciated.

[JaylinYu]

Looking for feedback from @ElectricEra and @yacinehmito