MQTT client shutdown and reconnect

[simonlbn]

It seems to me that the current MQTT client code does not support shutting down the client (including terminating the thread), nor reconnecting to an MQTT broker if the underlying channel needs reconnect. Does this sound correct?

Assuming this is true, is there a preferred pattern for such cases to follow?

For the shutdown case, I assume adding an explicit shutdown API function and channel command which make the thread exit (potentially after some kind of internal shutdown). Does that sound sane?

For the connection failed case, I can't see any easy way of handling this since the mqtt client in itself can't really reconnect the channel, and even if it could it wouldn't be able to resubscribe (not keeping track of what is subscribed to). While in theory I guess you could try and use the existing thread with new channels supplied by the application, this seems error prone to me. Therefore it seems sanest to me, at least for the time being, not to try and handle this more than perhaps setting an error in the client struct, and then make application shut down and start up a new mqtt_client.

I'm not certain the best way for handling these cases, so that's why I thought it made sense to file an issue rather than just a patch. I will be happy to work on the relevant coding. (As may be guessed, this came up with coding the MQTT example).

[eerimoq]

Usually modules have start and stop functions, at least drivers. Other than that there are no patterns that I can think of now.

The MQTT module needs some redesign to integrate more features seamlessly, and to simply improve the user experiance. It was some time since I read the MQTT module code, and I'll have to invest some time in reading it before I can give any good advice in how to improve the module. I'll hopefully have a look in the weekend, and then come back with a more useful answer.

[simonlbn]

OK, having different _init and _start might make this a lot cleaner.. then you could e.g. do

mqtt_client_init(&client...);
mqtt_client_set_last_will_and_teastmeant(&client, &msg);
mqtt_client_start(&client);

etc. and for disconnected lower level channel
mqtt_client_stop(&client);
// Reconn new channels
mqtt_client_set_channels(&client, &chan...).
mqtt_client_start(&client);

Or possibly just pass channels to _start.

Do you expect to have time to look at this over the next ~1 week or so? I have somewhat more time than normal this week due to travel, so it's mostly that I wonder if I should look at MQTT or more device drivers etc :-).

[eerimoq]

Sorry for the late answer. I didn't have time to look into the MQTT module, and will likely not find time for it in the near future.

But, yes, _init() initializing the object, and then _start() and _stop() and possibly setters for data not passed to _init() sournd like a clean approach.