search

espressif / esp-mqtt

ESP32 mqtt component
Apache License 2.0
603 stars 255 forks source link

Non-stable behavior (IDFGH-5923) #207

Closed goofy2k closed 3 years ago

goofy2k commented 3 years ago

I use esp-mqtt and wifi-client and observe strange behavior that seems to depend on the logging level. When I log only for errors, my app "hangs". However, it does report reception of MQTT message sent by an other device. When I increase the logging level to debug, I get a stream of "esp_timer: timer queue overflow" message with now and then the "Sent PING successful sequence". Again it reports received messages.

It could well be that the root cause is in different part of the app than esp-mqtt.

When I increase the logging level further to verbose, the app runs! It continuously displays the following message: "MQTT_CLIENT: mqtt_message_receive: transport_read(): no data or EOF" Is this normal behavior?

david-cermak commented 3 years ago

@goofy2k Could you be more specific on the "strange behaviour", please? I haven't noticed anything unexpected, but yes, with the debug level set, all the mqtt partial reads and ping requests/responsed are displayed, too. I don't think there's anything wrong with the logging severity, as for example arduino is build with CONFIG_LOG_DEFAULT_LEVEL_ERROR=y and arduino users do not complain about stability issues.

When I increase the logging level further to verbose, the app runs! It continuously displays the following message: "MQTT_CLIENT: mqtt_message_receive: transport_read(): no data or EOF" Is this normal behavior?

Yes, this is expected, when no active communication, mqtt client checks for incoming data in regular intervals (by default MQTT_POLL_READ_TIMEOUT_MS) and prints out this verbose message:

https://github.com/espressif/esp-mqtt/blob/master/mqtt_client.c#L1093

goofy2k commented 3 years ago

@david-cermak, thanks for your reply. Clear, the mqtt client does it's work as expected. The cause of the unexpected behaviour was in a different part of my code. My sight on this was obscured for two reasons: 1) the occurrence of the error depended on the logging level 2) the async nature of mqtt. I solved the issue by increasing stack size. I propose to close this issue.