Pierre Fersing

Agree that manual ack could be added. I've closed the issue because the issue was about acking after on_message. Side note on back pressure: I use to do back pressure...

I'm able to reproduce this with the sample code your provided and killing the broken after log of `In main loop`. I've used Mosquitto rather than emqx but this shouldn't...

Closed as we can't reproduce the issue. Feel free to reopen if you have more information to reproduce the issue.

I'll need to information on how to reproduce this bug, as I never had publish() which hang the program in my usage. #710 could be the same issue: a publish...

This will cause a breaking change. Any user that have a working client with MQTTv5 (but don't need reasonCode or properties) will have their client broken. My two idea to...

I've just seen that we already had something similar to you change with the on_connect callback. But I still think we should avoid breaking. After a second though I think...

Thank for your contribution. Closing this PR because #802 fix the same issue as this PR.

With the sample code from https://github.com/eclipse/paho.mqtt.python/issues/505#issuecomment-848309769 I'm able to reproduce the issue. In that code sample, the issue is in stop() function we call publish() which only *submit* a packet...

I doubt sharing a Client() over multiple process is something we can and want to support. The paho Client() can not be made picklable since it contains a socket. >...

I'm not sure the message being dropped is a bug. You do a publish with QoS = 0 which is according to MQTTv3.1.1 standard: > The message is delivered according...