MQTT: publishing with QoS 1 (related to pinned issue)

[pmf]

Describe the bug
Hm, I think I'm now running into something similar to what is described under #228 (the pinned issue). Where it differs is that I don't get a memory leak when publishing QoS 1 messages, but a disconnection.

I'm using a loop that does nng_recvmsg() on the MQTT socket to receive, and using nng_sendmsg() on the MQTT socket to send, and everything works well until (like you mention) I set QoS to 1.

I tried to follow the advice (using dedicated AIO for publishing) by creating a nng_ctx on the socket, an associated aio and sending via nng_aio_set_msg() and nng_ctx_send(), but I see no difference. In both cases (sending via nng_sendmsg() and sending via context/nng_aio_set_msg()/nng_ctx_send()) it works fine with QoS 0 and causes a disconnection with QoS 1 ... disconnect callback is called, with the value of NNG_OPT_MQTT_DISCONNECT_REASON being 139 (which is SERVER_SHUTTING_DOWN, but the server keeps running fine). Whether I receive via a receive loop or use a receive callback does not change this behavior.

Using an explicit nng_aio_wait() after nng_aio_set_msg()/nng_ctx_send() does not help (just FYI).

Do you have an example application of how to handle publishing QoS 1 messages? The demo mqttv5_client application does not have a concurrent receive loop for the MQTT socket when in publishing mode, so it's probably not quite the same. I'm pretty sure I misunderstood the hint "Plz allocate a new aio for sending/receiving MQTT QoS 1/2 msg" from #228 in some way or misapplied it, so an example would be very instructive.

Expected behavior
I have an example of an MQTT application correctly publishing with QoS 1 and concurrent receive loop (or receive callback).

Actual Behavior
I do not have an example of an MQTT application correctly publishing with QoS 1 and concurrent receive loop (or receive callback); when trying to follow the hint from #228 and use a dedicated aio for publishing, I get disconnected with reason 139 (SERVER_SHUTTING_DOWN).

To Reproduce
Could strip down my example if needed.

Environment Details

• NanoSDK/NNG version: NanoSDK (commit e5516c1)
• Operating system and version: custom ARM Linux (32 bit)
• Compiler and language used: n/a
• Shared or static library: n/a
• Remote MQTT Broker info: nanomq (commit 4d750bac25e01d85fb708d6d2b01d365165ab3a0)
• Messaging scenario: n/a

Additional context
n/a

[pmf]

Disconnection was due to my low message size taken over from the example (not sure how changing the QoS played into this). Closing for now; sorry for the noise.

[JaylinYu]

nng_aio is painful to learn, we deliver ACK msg in aio callback, this is why nng_sendmsg is not compatible.