Only receiving messages from MQTTSubscribe when next MQTTPublish is happening

[fmuller-pi]

Hi,

I am using an MQTT connection to communicate with my Cloud. Everything works pretty well I would say, except for the messages coming from the Cloud to my ESP. After I connect successfully to the Cloud with MQTT, I do a MQTTSubscribe (where I pass my message handler for incoming messages from the Cloud) that is successful. And then I do MQTTPublish when I need t post something to the Cloud. The problem is that ESP seems to be processing coming from the Cloud in my message handler only when I do a publish. Which is quite annoying cause I don't publish all the time and this can delay a lot the processing of my message from the Cloud. Any idea why my code could be acting that way? I am using the latest ESP_RTOS_SDK, and following their MQTTEcho example, and I checked on the Cloud side and I am certain the message leaves the Cloud right away when it needs to be sent.
So the problem is definitely on the ESP side...

Thanks for your help!

[fmuller-pi]

Anyone having a suggestion on this?

I looked in there SDK, and to me, when looking at the function cycle() in the MQTTCLient.c file, it feels like there are only processing delivered MQTT messages when the switch case PUBLISH happens... Which would validate the behaviour I am observing here. Am I right? Or am I missing something?

Thanks,

[fmuller-pi]

It has been many months but since no one never answered, I'm going to explain what was the problem and give my solution to it.
NOTE: This is using the ESP8266_RTOS_SDK v3.1

Basically, the problem laid in the fact that I was open my MQTT bridge with an SSL connection. The example from Espressif works just fine when the connection is NOT an SSL one, but with the SSL, a bunch of bugs starts appearing.
So to make it short, because CONFIG_MQTT_RECV_CYCLE == 0 by default, you start hitting timer expired conditions everywhere when reading with the SSL read function incoming messages (even tho the messages are coming in properly). Then, increasing the CONFIG_MQTT_RECV_CYCLE, other delayed issues start to appear because MQTTRun isn't yielding by default to other tasks...

Anyway, in my case, I decided to use MQTTYield instead of starting the MQTTRun task. It gave me more flexibility on how I wanted to set my MQTT flush of incoming messages an all.

Espressif won't fix this since they are working on a new release that isn't using the MQTT Paho library anymore. But in my case, upgrading the SDK at that point in the release of our product wasn't an option, so I had to deal with what I have been done in the SDK v3.1...

Hope that can help others that might have encountered that type of issue.

Cheers