CC3235SF: Device gets stuck when MQTTClient_publish is called in defined scenario.

Darpan Noel DSouza

Part Number: CC3235SF

Hi,

I have observed that when the device is setup and connected to the broker there is no issue that is observed. But when the AP to which the device is connected to looses internet access the device gets stuck after MQTTClient_publish(....) API is called.

The general observation is that when the device is connected to the AP and the internet access is turned off, there is an interval (I guess TCP Keep Alive) which detects that the internet is not connected and then triggers the respective MQTT callback. But within this period if I publish any message to the broker using MQTTClient_publish the device does not return from this funtion.

In order to fix this issue, after reading a little I came across the MQTT Client parameter blockingSend which was set as true. When I set this to false and recreated the same condition the issue seemed to have been solved.

There are two questions that I had relating to this:

1. What all are the affects caused by setting the blockingSend parameter to false??

2. When set to false the MQTTClient_publish(....) function does not return any error. The return value observed is 0. Is there a way to identify this situation??

Regards,

Darpan.

typedef struct MQTTClient_Params{ /** client id */ char *clientId;
/** * Operate in MQTT 3.1 mode: * - false: 3.1.1 (default) * - true - 3.1 */ bool mqttMode31;
bool blockingSend; MQTTClient_ConnParams *connParams; /**< pointer to connection params */
} MQTTClient_Params;

over 5 years ago

0 Kobi Leibovitch over 5 years ago

TI__Guru 63006 points

Hi Darpan,

This seems like a bug. I'll need to check it.

With the blockingSend == TRUE, the publish API will block until the MQTT PUBACK (from the broker) will be received.

When the flag is FALSE, the Published Message will be sent and the PUBACK will be received as an event.

The MQTT Disconnect (if i understand correctly, you are getting this one), should have released the block. According to you it doesn't (which seems like a bug).

You can set the flag to FALSE and use the PUBACK event as an indication that the message was sent (and received) correctly.

Br,

Kobi

0 Darpan Noel DSouza over 5 years ago in reply to Kobi Leibovitch

Intellectual 685 points

Hi,

Yes, as observed this block does not get released when the MQTT Disconnect event is triggered.

Just to give more clarification I am using QoS 0. This is a fire and forget process. Does this implementation also wait for a PUBACK from the server??

Regards,

Darpan.

0 Kobi Leibovitch over 5 years ago in reply to Darpan Noel DSouza

TI__Guru 63006 points

With QOS 0 - we are not waiting for the ACK, but i don't see that the PUBLISH call gets stuck in this case.

It looks like we have an issue upon disconnection (in this use case), which is in debug now.

br,

Kobi

0 Kobi Leibovitch over 5 years ago in reply to Kobi Leibovitch

TI__Guru 63006 points

What sdk are you using?

Are you using MQTT_IF module?

The solution to the disconnection issue, is to use call both the MQTTClient_publish and MQTTClient_disconnect within critical sections (protected by the same mutex).

If you are using MQTT_IF, then the implementation of MQTT_IF_Publish should be updated as follows:

int MQTT_IF_Publish(MQTTClient_Handle mqttClientParams, char* topic, char* payload, unsigned short payloadLen, int flags)
{
    int ret;
    pthread_mutex_lock(mMQTTContext.moduleMutex);
    if(mMQTTContext.moduleState != MQTT_STATE_CONNECTED){
        LOG_ERROR("not connected to broker\r\n");
        pthread_mutex_unlock(mMQTTContext.moduleMutex);
        return -1;
    }

    ret = MQTTClient_publish(mqttClientParams,
                              (char*)topic,
                              strlen((char*)topic),
                              (char*)payload,
                              payloadLen,
                              flags);
    pthread_mutex_unlock(mMQTTContext.moduleMutex);
    return ret;	
}

Br,

Kobi

Wi-Fi

Wi-Fi forum

CC3235SF: Device gets stuck when MQTTClient_publish is called in defined scenario.